Every agent call, through one governed gateway

Most companies now run agents that call tools on their own: an agent that triages new business, one that opens release pull requests, one that cleans up cloud storage overnight. Each was connected to its MCP servers with whatever token got the project moving. Ask, per agent, what it may call, what it did call last week and who approved that, and the honest answer is usually that nobody knows.

Turning on enforcement without that knowledge is how working agents break, so teams leave it off, and the standing risk stays where it is. When something does go wrong, say an agent starts calling tools it has never needed in the middle of the night, there is no single place to stop it and no single record of each call, its decision and its reason that a responder or an auditor can rely on.

Agent access is granted in a hurry, reviewed rarely and spread across as many places as there are tools. Governing it means one place every call passes through, evidence before enforcement, access sized to the job, a fast way to stop one agent, and a record you can hand to someone else.

Agent governance sits between teams. Security sets the limits, the platform team runs the agents, compliance needs the evidence, and the AI team builds what the business asked for. Each of them gets something specific from one gateway.

Calls over MCP, through the API and from the app all take this route. A call that fails a step stops there; the steps after it are recorded as never reached, and the decision is still written to the trail. This is what you watch in the demo above. In plain terms, each step asks one question.

Every company starts in watch-only, sometimes called shadow mode. Calls are assessed at every step and recorded exactly as they would be under enforcement. When a call crosses a boundary you are designing, it is marked Allowed (would be blocked) and runs anyway. After a week of real traffic you know, per agent and per tool, what enforcement would have stopped and whether any of it was work you need.

Sign-in, licence, consent and company separation are never in watch-only: an expired sign-in or a request for another company's data is refused in both modes. Watch-only covers the decisions you are tuning, which are whether a tool is in scope, the real-time stop check and the threat check. When the evidence says a boundary is right, switch to enforce, for the whole company or for one capability at a time.

Most standing risk in an agent fleet is access that was granted and never used. The scope designer shows, per agent, what it holds beside what it has used, and proposes keeping the one and removing the other. In the demo, the release helper holds four tools and has only ever opened pull requests; the proposal keeps that one and removes rollback, bucket deletion and policy changes.

Nothing changes until a person approves. The proposal is evidence for that decision and cuts nothing on its own, and the approval is recorded with the change. Because watch-only shows what a narrower scope would have refused, a reviewer can approve with confidence and does not need to keep everything just in case.

Calls that cross a boundary land in the actions queue for a person to decide. There are a few choices, in the product's own words. Block cuts the agent back to its minimum permissions and clears its session, so it stops acting through Aribot. Reduce access removes the risky permission. Reissue access issues a new, narrower permission and retires the current one.

The product is careful about what Block does and does not do, and so is this page. It stops the agent here, at the gateway. Sessions the agent holds in other systems end only if sign-out signals to your identity provider are set up, and the integration health screen says whether they are. A responder is never told an agent has stopped everywhere when it has only stopped in one place.

Each call becomes a record: the agent, the tool, the decision, the step that made it and the reason. So does each mode change, each scope change with the name of whoever approved it, and each action from the queue. Refusals are recorded as carefully as approvals. The trail is tamper-evident, and it exports, so an auditor or an incident responder works from the same record the platform team does. In the demo you can download the illustrative trail as a file.

Ovenden Mutual is a fictional insurer with four agents in production: an intake triage agent, a release helper for the platform team, a broker research agent for the sales desk and an overnight ops clean-up agent. Its head of platform, Priya, brings them under governance on a Monday. The agents already sign in over OAuth, so they appear in the fleet on their first call; nothing in their code changes.

For the first week the company runs in watch-only. Every call is assessed and recorded. By Friday the trail shows three things. The ops clean-up agent tried to create a new access key, which it was never granted. The broker research agent tried to export broker contacts to an outside address, which matched a known threat. And the release helper, which only ever opens pull requests, still holds bucket deletion and policy changes from the day it was set up. Nothing was stopped; everything was recorded as would be blocked.

On the second Monday, Priya opens the scope designer and accepts its proposals: keep what each agent used, remove what it never needed. The CISO, Daniel, approves. Then the company switches the release helper's bucket deletion to enforce first, while everything else stays in watch-only for two more days. Nothing breaks, so Ovenden switches the whole company to enforce on Wednesday.

On Thursday night the ops clean-up agent starts calling tools it has never needed. Each call is stopped at Allowed? and lands in the actions queue. The on-call engineer chooses Block. The agent is cut back to listing storage and its session is cleared, and its next call outside that minimum is stopped at the real-time stop check. In the morning, the compliance lead exports the trail for the incident file: every call, every decision, the scope approvals and the block, with names and times.

In Aribot, Agent Governance has an overview of the fleet and its decisions, a fleet list of every agent with its identity and cohort, the scope designer, the actions queue, an integrations screen that shows which identity connections are healthy, and an interop standards screen. The overview says plainly how many checked actions would be blocked once blocking is on, with the period it covers, so the decision to enforce is made from numbers.

Agents are onboarded three ways, and all three end in the same record: automatically on first sign-in, in bulk from a list of agent ids, or by another agent through the onboarding tool. The onboarding guide walks through licence, sign-in and bulk onboarding step by step.

The free AI readiness self-assessment shows where a company stands against the EU AI Act, the NIST AI RMF and related frameworks. Aribot is where that becomes working controls: governed agents, threat models, code and cloud findings and framework coverage. Ayurak Trust holds the evidence: detailed assessments reviewed with Ayurak's team, using assessment templates by Aristiun built from official framework text, with tamper-evident reports. The agent trail from this page is the kind of evidence those assessments ask for when they ask how automated systems are kept within limits.

The gateway speaks the standards your identity and agent stack already uses: MCP for tool calls, OAuth for agent sign-in, SCIM for provisioning, SPIFFE for workload identity, OpenFGA for a view of access in force and A2A agent cards for onboarding. The evidence maps to the EU AI Act's expectations on human oversight and record-keeping, the govern and manage functions of the NIST AI RMF, ISO/IEC 42001, and the access control and logging expectations of ISO 27001 and SOC 2.