Deploy the governed endpoint
Before you start
- A running platform.
- An identity provider agents' operators can authenticate against.
1. Decide where it runs
| Option | Suits |
|---|---|
| Alongside the platform | Most deployments — one trust boundary, one operational surface |
| Separately | When agent traffic must be isolated or scaled independently |
Either way it is a client of the API, holding no data and no business rules. Its privileges are whatever the calling user's are.
2. Deploy it
Point it at the API. It needs no database credentials and no privileged token of its own — if it is asking for either, something is misconfigured.
It performs no authentication itself: it forwards the caller's bearer token to the API, which is what makes the agent act as the signed-in user.
3. Scale it
Requests are stateless, so it scales horizontally. Because it holds no session state of its own, any replica can serve any request.
Where a two-step confirmation is in flight, the pending step is held in shared state so a commit reaches the same conclusion regardless of which replica handles it.
4. Verify governance
Do this before letting agents connect. It is the check that matters.
- Connect as a restricted user and confirm the agent sees only what that user sees.
- Ask for a masked field and confirm the mask comes back — not the value, and not an error.
- Attempt a mutation as a read-only user and confirm it is refused.
- Check the audit log records the actions, attributed to the user.
An administrator's agent working correctly proves nothing about enforcement, because an administrator can see everything anyway. The test that means something is the restricted account.
5. Monitor it
Watch request rate, error rate, and latency. Authentication failures and permission denials are recorded as security audit events — a rise in either is worth investigating, since agents do not usually develop new intentions on their own.
Next
Last verified against commit f7daa483 (2026-08-03)