Deciding every agent call
Governing AI agents is about the identity an agent uses: who owns it, what it holds, and how to stop it. This page is about the calls the agent makes through RapidValue. A tool call is a form of access, so it is decided the way access is decided: against a grant, an owner and a set of rules, with a record of the answer.
The boundary is the same as everywhere else in the product. RapidValue decides the calls that pass through RapidValue. It does not see what an agent does inside another vendor's application, and the chain view labels that as unknown.
Where this runs today
There are two MCP surfaces, and they are not in the same state.
| Surface | What it is | Status |
|---|---|---|
| RapidValue's own MCP endpoint | Tools to read and explain governance data, and for people to request access, decide a task and propose connector onboarding | In production since 30 September 2026; each tenant opts in |
| The MCP gateway | One endpoint per protected system, in front of your own MCP server or API | Accepted on staging since 20 October 2026, for the load proof and for pilots. Closed in production until the load proof passes and a new decision is recorded |
Everything below about the gateway describes what is built and running on staging.
Every call is decided
At the gateway each tools/call is evaluated before it goes upstream. The evaluator
reads the agent's grants, the person's rights (for a person's assistant), the
permission's runtime terms and the tenant's guardrails, and writes one decision row.
Decision rows are sealed every hour, so a later edit would show.
Each protected system starts in observe: the call is decided and recorded, then forwarded whatever the answer, so you can see what would have been refused before anything is blocked. An administrator switches a system to enforce after watching its own calls. In enforce:
- the gateway issues a single-use execution authorization for exactly this request (its digest), consumes it at once and only then sends the call, so a second attempt with the same authorization is refused;
- the system's own credential is injected from the vault, so the agent never holds it. An admitted agent that does hold an active credential on a destination system is raised as a finding;
- the receipt records the upstream status, a hash and the size of the answer, never its content.
A system can also run in tier-3 mode: the decision stays on the control plane and the customer's own agent sends the call with a credential from its local vault, over a pinned client certificate. No credential crosses the wire.
A person's assistant is decided for two
Every OAuth client a person signs into is its own governed agent identity. When that assistant calls a tool, the decision is taken for two subjects: the agent must hold the grant and the person must be entitled. The assistant never gets a right its person does not have. Every decision names both, and the person is taken from the token, never from a tool argument.
Runtime terms
The owner of a permission writes its runtime terms: the purposes it may be used
for (from the tenant's own closed list, in four languages), how long a grant lasts,
what each call needs (auto, record, confirm or jit), the consequence class and
what is prohibited. Terms are versioned and pass the IAM guardrail check before they
are saved.
The person accountable for an agent accepts a terms version in the RapidValue UI. The acceptance becomes an ordinary access request that the terms approve as the owner's standing instruction, unless the person accepting them also wrote them. Each terms version is reviewed yearly by the permission's owner, never by its author. A rejection withdraws the version and ends every grant that existed only because of it.
When the answer is "not yet", the owner is asked
On a flat deny an agent can only retry. So in enforce, when the owner could lift the refusal, the gateway files the request at the resolved owner and tells the agent "approval requested", with a reference to poll.
| What the gateway finds | What the owner receives |
|---|---|
| No grant, and the permission has no terms | An access request on the normal approval chain |
| No grant, and the permission has terms | Nothing: the accountable person has to accept the terms first |
| The permission needs just-in-time access, or an autonomous agent makes a privileged call | A JIT request |
| The grant's window has ended | A new access request |
The terms say confirm |
A confirmation of exactly this call, by its request digest, usable once |
Some refusals are never escalated, to protect the owner's attention: a suspended or killed agent, a revoked credential, a segregation-of-duties conflict, a permission that cannot be requested.
There is one open request per question. Each owner has at most 20 open requests by default (a tenant setting), and each request has a deadline, 24 hours by default. At half the deadline it is rerouted to the IAM team; at the deadline it expires and the call stays denied. An agent is never granted access by default.
Agents that speak UMA 2.0 can take the bound path instead: a challenge, a ticket, a DPoP-bound requesting party token and the same request to the owner. RapidValue ships a small client adapter for that path.
Missions
A mission is an agent's access request read as one bundle: who asked, for which agent, for what purpose, under which terms version, for how long, and where each grant stands. It is shown on the agent's page. When the mission expires, or the requester or an administrator ends it with a reason, every grant in it ends in one operation. The next call is refused at once, and reconciliation removes the access at the target.
Agent chains
When agent A asks agent B to act for it, RapidValue governs the chain instead of passing it through. B exchanges A's token at RapidValue's token endpoint (RFC 8693 token exchange) and receives a token that names every agent in the chain. A call is allowed only when the person and every agent in the chain may make it.
A chain is refused when it is deeper than the tenant allows (three agents by default, five at most; the person does not count), when it contains an unknown, ungoverned or blocked agent or one without the grant, or when a link was not declared beforehand. Holding the same grant is not consent to be acted for: administrators declare on the agent's page which agent may act for which. The chain is sealed on every decision row.
Approved MCP servers, and tools that change
- A catalog of approved MCP servers. An administrator lists a protected system with a description and a data classification. People see its owner, tools and terms, and the person accountable for an agent requests its permissions through the existing request flow.
- Tool definitions that change. The gateway fingerprints every tool an MCP server lists. When a mapped tool's description, schema or annotations change after it was reviewed, or the server stops offering it, the gateway holds that tool: refused in enforce, flagged in observe. The system's owner gets an inbox item to compare the old and new definitions and accept the new one.
The owner ledger
The owner of a permission sees, per agent call, what was promised (the terms accepted before the call), what was decided, what was consumed and what was observed. A call without a receipt is never shown as a success. The same facts go into the per-agent evidence pack, described in Governing AI agents.
Known edges, published rather than discovered
- The gateway is not in production yet. It runs on staging for the load proof (gateway overhead at most 100 ms at p95) and for pilots.
- The effect at the target is not observed. A receipt proves the upstream answered, not that the target changed. Reconciliation is what shows the target's state.
- Calls outside RapidValue are not seen. An agent's own platform connectors and other MCP servers are outside the gateway, and the chain view says so.
- Chains on the bound path are not built, and a chained deny is refused rather than sent to an owner.
- Tier-3 gateway calls in the managed SaaS wait for a validating TLS terminator in front of the control plane. Until then they are not dispatched there.
- The autonomy tier is recorded but not enforced on RapidValue's own endpoint.
Further reading: