Procurement Admin
Setting up AI assistants and interfaces
MCP server and REST API, personal AI access and technical keys — what you allow, what you limit and how you end it again.
- Duration: 20 min
- Level: In depth
- Read first: Users and access
e-Request does not embed a model of its own. What it offers is a connection: your own AI assistant — Claude, an in-house model, whatever you use — connects to your instance through the MCP server. For systems without a model there is the REST API. Both are paid add-ons; they have to be in your licence, otherwise the endpoint does not answer.
This lesson sets up both. How an individual person connects their assistant is covered in Connecting your own AI assistant.
Two kinds of access
| Personal AI access | Technical access (service account) | |
|---|---|---|
| For whom | one person and their assistant | a system, an integration |
| Sees | exactly what the person sees in the portal | the whole tenant, no department boundary |
| MCP server | read, optionally also write | read only |
| REST API | — | read, optionally also write |
| Issued by | the person, once you allow it | the administration |
| In the log | the person, “via AI assistant” | the service account, “via API” |
The rule of thumb: when a person works with their assistant, use personal access. A technical key sees everything and belongs to nobody — it is meant for systems, not for people.
Settings → MCP server
This page shows the endpoint the assistants need, the tools the server offers, and four switches.
Allow personal AI access — off by default. Only once you switch it on can people issue themselves access in their profile or connect their assistant with “Sign in with e-Request”. There is no approval per person: once on, it applies to all three roles, and each person gets exactly their rights from the portal.
Valid for at most (days) — how long a personal access may run at most, between 7 and 365 days. The person chooses within that limit. A week before it expires, they get a reminder by email.
Pass amounts to AI assistants — on by default. Budgets and offer totals then reach the model. Through personal access nobody sees more amounts than in the portal; a technical key sees all of them. Switched off, the server returns no amounts for anyone — the assistant then says it cannot answer price questions.
Internal writes only — off by default. An assistant never carries out binding steps on its own anyway (see below). With this switch it does not even offer them, not even for confirmation. What remains is internal and reversible: creating drafts, changing fields, preparing answers, maintaining the shortlist. That answers the first question of any IT security review: “Can the assistant send anything outside?” — No.
What an assistant may do — and what not
An assistant with write access works in the purchasing process: requests, offers, questions, suppliers, contracts, appointment findings. What it may do is decided by the same permissions as in the portal. A department user cannot do more through their assistant than in the portal.
Every step has an impact class:
- Internal and reversible — create a draft, change fields, put an offer on the shortlist, write an answer, leave a comment. The assistant does this at once.
- Binding — anything that reaches suppliers or cannot be taken back: publish, reject, award, write to a supplier, propose dates, send for signature, terminate, delete. The assistant does not do this. It puts the step forward for confirmation and gives the person a link; only their click in the portal carries it out, as them. A confirmation is valid for 60 minutes and lapses if the record has changed in the meantime. Only the person can confirm — not even you as the administration can do it for them.
Never through an assistant: administration. Users, roles, keys, settings and categories stay in the portal. Uploading documents and creating a new contract also happen in the portal.
Settings → Technical access
Here you issue service accounts for systems: with read access or additionally with write access for the REST API. The key is shown exactly once — copy it to its destination right away. A lost key is replaced by issuing a new one.
Two things to know before you issue one:
- A technical key sees everything in the tenant. There is no department boundary.
- It works for the REST API and the MCP server. On the MCP server it stays read-only, even with write access for the REST API. Writing over MCP runs only through personal access, so that every change carries a name.
You manage a service account; it manages nothing: users, keys and settings are out of its reach. Rotate its keys when staff change — it belongs to no person, but someone knows it.
Overview and revocation
Under Settings → MCP server → View all AI access you see every personal access on your instance: whose it is, when it was last used, when it expires. You can revoke a single one or all of one person’s access at once.
Access also ends on its own:
- when it expires,
- when the person is deactivated,
- with SSO, when the person has not signed in to the portal for 14 days — e-Request learns of a departure in your identity provider only at the next sign-in, and this keeps the gap short,
- when you switch off “Allow personal AI access”.
In the log
Every change made through an assistant appears in the activity log with the person who acted and the note “via AI assistant”. Changes through the REST API carry “via API” and the name of the service account. That way you can always tell what happened in the portal, through an integration or through an assistant.