Give each AI agent the access its job needs.
Agents act in your systems with real credentials. Aribot lists every agent you run, sizes its access to its task, checks each call as it happens and keeps a record you can show an auditor.
Agents act with access nobody sized
An AI agent does work on someone's behalf. To do that it needs access: a token for the ticketing system, a key for a cloud account, a seat in a code repository. In most companies that access is granted the way a contractor's badge used to be, broadly and in a hurry, so the work can start. It is rarely sized to the task and almost never taken back.
The people responsible then cannot answer basic questions from their current tools: how many agents run, what each one can reach, which permissions each has used, how fast one can be stopped if it starts deleting records at three in the morning, and how to show afterwards what happened.
Identity tools see a service account. Logging tools see a request. Neither knows which agent made the call, what it was meant to be doing, or whether the call was inside the authority someone approved.
Agent governance in Aribot closes that gap. It keeps the list of agents, holds each one to the access its job needs, checks every call as it happens, and keeps the record. The rest of this page walks through each part as you would meet it in the product.
Who uses it
You need a list of every agent with access to company systems, what each can reach, and a way to stop one during an incident.
One fleet view, the same checks on every call, and a Block action that takes effect on the agent's next call, with the decision written to the record.
Your teams connect agents to ticketing, code, data and cloud accounts faster than any access review can follow.
Agents that register as they connect, a scope designer to size access before go-live, and watch only so nothing in production breaks while you learn.
You are asked to launch agents quickly and then to answer for what they did.
Evidence for every launch decision: what the agent asked for, what it was given, what it used and what was refused, per agent and per cohort.
Auditors ask who approved an agent's access, whether anyone oversees it, and what it did on a given day.
A per-agent assessment, traceability from any action back to the permission that allowed it, and a tamper-evident audit record you can re-check.
One hub for the whole fleet
The agent governance hub is where every agent your company runs through Aribot is listed, with its permissions, its activity and its record. It is organised in four areas, each with its own tabs, and the main tables can be exported as CSV or JSON for your own reporting.
Every agent your company runs through Aribot, its state, and each call it made with the decision taken. Live controls suspend or isolate an agent from the same screen.
What each agent may do, what was removed, and which part of your architecture it belongs to. Agents whose origin cannot be traced are counted and shown as provenance unknown.
The record of every decision, the limits on what an agent may spend where agents pay for things, and the evidence that the controls ran when they should have.
The rules an agent cohort follows and the labels on your data that say where it may and may not flow.
A strip at the top of the hub shows the mode the company is in, watch only or blocking, so nobody reads an activity feed without knowing whether its refusals were enforced. Administrators can change the mode from the same strip.
Every call meets the same checks
An agent call can arrive over MCP, through the Aribot API or from the app. Each one passes the same ten checks in the same order before anything happens, and the outcome is recorded whether the call ran or was refused. There is no side door where an agent can skip a check because it used a different route.
The checks are simple to read on the hub. Is this agent who it says it is? Is it covered by your licence? Did the person or system it acts for consent to this kind of action? Is the action inside its role and your company's data? Is it within the permissions it was given? Has anyone stopped or narrowed this agent since its last call? Does the request match a known threat? Only then does the action run, its use is counted, and the result is written down.
The stop check is the one an incident depends on. When someone blocks an agent, that decision applies to its next action, wherever in the fleet the agent is running.
Watch only first, then blocking
Switching on enforcement on day one is how governance projects get switched off on day two. Aribot starts in watch only. Every call is checked and recorded exactly as it would be under enforcement, but calls that fail a check are allowed through and marked "would be blocked" in the activity feed.
That list is the most useful thing a platform team can have before going live. It shows which agents ask for more than they were given, which permissions are missing for a legitimate job, and which calls you would never want to run. Fix the first two, keep the third on the list, and move the switch to blocking when the would-be-blocked list matches what you intend to stop.
In blocking mode the same refusals take effect. The activity feed then marks those calls "Blocked", and the scope designer tells you which mode its result will be enforced under.
Size an agent's access before you grant it
The scope designer is where a new agent's access is agreed. You pick the permissions the agent should request. The designer shows what it would be granted and what would be withheld, once its role, its past use and current threats are taken into account, and why each withheld permission was left out.
That turns an access debate into a short review. The team building the agent sees which requests will not survive and can change the design or make the case for an exception. The security team gets a concrete list of permissions to review.
Withheld permissions are the ones that would leave an agent with authority beyond its job. If one of them later turns out to be needed, it shows up in the activity feed as a refused call with a reason, which is the evidence for granting it.
An assessment for every agent
The fleet assessment runs a set of checks on each agent and lists the fleet worst first. Each agent's page shows its verdict, the checks behind it with their reasons, how much of its granted authority it has used, and its history.
The verdicts are worded to be read by someone who is not a specialist, and each one says what to do next. The one the product guards most carefully is the absence of a result. An agent that has never been assessed, an agent whose checks could not reach a conclusion and an agent that came back clear are three different facts, and the screens keep them apart by word and by shape.
Every count is shown out of the number it belongs to. "Two agents need attention" means little if forty could not be checked, so both numbers are always on screen.
Every check that could be run came back with nothing wrong.
Nothing to do now. Check again after any change to the agent's permissions or labels.
At least one check had nothing to work with: no permission labels, no issued access, or no threat data to compare against.
Add what is missing, then run the assessment again. Until then the agent is unchecked.
A check found a real issue, such as a known low or medium threat that affects one of the agent's permissions.
Narrow its permissions, reissue its access, or accept the risk and record why.
A check failed: the agent acted outside its access, its access lets data flow where labels forbid, or a known high-risk threat matches.
A person needs to act now. Running the assessment again will leave it blocked.
The agent exists in the fleet but no assessment has been stored for it yet.
Run the assessment. This state is shown apart from the four verdicts so it is never counted as a result.
An actions queue with the next step for each agent
Everything the assessment finds that can be acted on lands in the actions queue, grouped by the action that would fix it and ordered worst first. Each entry names the agent, the check that raised it, when it was checked, and links to the agent's assessment.
Before anything is applied, the confirmation states what the action does and what it does not do. For Block, that includes whether sessions the agent holds in other systems will also end, which depends on whether sign-out signals to your identity provider are set up. Today only Block can be applied from the queue. For the other actions the queue says why next to the entry, and your team makes the change where the permission is issued. Nobody believes a fix was made when it was not.
An empty queue is shown together with how many agents could not be checked. An empty queue over a fleet that was mostly unassessed is a gap to close, and the screen says so.
- Block. Cuts the agent back to its minimum permissions and clears its session, so it stops acting through Aribot. This one can be applied from the queue.
- Reduce access. Recommends letting the current safe action finish, then removing the risky permission.
- Reissue access. Recommends replacing the current permission with a new, narrower one.
- Hold back access. Recommends not granting a changed permission the next time the agent asks.
- Confirm. Recommends that an owner confirms who may see the data this agent can reach.
Trace any action, prove the record
Traceability works in both directions. Start from an event and walk back to the permission that allowed it, who issued it and when. Start from a permission and walk forward to everything that was done with it. The first answers an incident question, the second answers an access review.
Every decision, allowed or refused, is written to the audit record. The record is tamper-evident: it can be re-checked at any time, and a later change to any entry shows up when it is. That is the evidence an auditor asks for when they want to know who approved an agent's access and what the agent did with it. The audit trail and AI cost page covers the record, and the spend it explains, in more detail.
The record can also be queried one action at a time. Paste an action reference into the lookup on the interoperability screen and you get the decision taken for that call.
Three ways agents come under governance
All three paths lead to the same record in the fleet, and all three can be run again without creating duplicates. The step-by-step onboarding guide shows each one with screenshots.
An agent appears in the fleet the first time it signs in through the Aribot connector or makes its first governed call. Nobody has to fill in a form, which is how a large fleet comes under governance without a project plan.
On the agent governance hub, Onboard agents takes a pasted list or a CSV column of agent IDs, puts them in a cohort and can set a threshold at which an agent is suspended automatically. Running it twice is safe: agents already known are skipped.
The same onboarding is available over the Aribot API and as the onboard_agents tool on the Aribot MCP server, so an administrator's own assistant can bring a fleet under governance in one request. It accepts plain agent IDs, A2A agent cards and MCP client details.
Licensed or refused
Every route into agent governance checks for an agent governance licence first, and refuses when there is none. That covers the hub, the API and the MCP tools. A company without the licence sees a request-access screen. Adding agents also needs an administrator, or an assistant whose sign-in was granted the right to manage agents, and every request stays inside the company it came from. The MCP route is held to the same rules as the API.
Works with the standards your identity team uses
Agents should not need a private protocol to be governed. Aribot follows the public standards your identity and platform teams already run, and an integration health page reports for each one what it will do in an incident, based on its settings and recent activity. An integration that is not set up is shown as not set up.
- MCP and OAuth 2.1
- Assistants and agents reach Aribot over the Model Context Protocol and sign in with OAuth 2.1, so each one arrives with its own identity and only the scopes it was granted.
- A2A
- Agents that publish an Agent2Agent agent card can be onboarded from that card, and Aribot publishes its own agent card and public signing key for agents that need to check who they are talking to.
- SCIM 2.0
- Agent identities provisioned in your directory appear in the agent directory and can be removed there with everyone else.
- OpenFGA
- The permissions in force can be viewed as relationships your team can read and query, including those that were removed.
- OAuth 2.0 Token Exchange
- An agent can trade its access for a limited token meant for one task, and other systems can ask whether that token is still valid.
- OpenID Shared Signals and CAEP
- When access is revoked in Aribot, a sign-out signal can be sent to your identity provider so sessions held elsewhere end as well, once you set up the receiver.
- SPIFFE
- Workloads that carry a SPIFFE identity can be recognised as themselves.
A first month at Quillmere Freight
Quillmere Freight is a fictional logistics company. Its teams run agents that match invoices, plan routes, triage support tickets and draft weekly reports, and a few assistants connected by individual staff. Every number below is illustrative.
Week one: the list
The platform team connects its agents to Aribot and adds a known list of twelve service agents in a cohort called operations. Others appear as they sign in for the first time. By Friday the agent list shows 46 agents, six of them assistants nobody had written down. The company is in watch only, so nothing has changed for any team.
Week two: what would have been blocked
The activity feed collects 140 calls marked would be blocked. Most come from the report writer, which tries to close tickets after summarising them, a permission it was never meant to have. The invoice matcher tries to export a customer list once, which nobody can explain.
Week three: the assessment
The fleet assessment comes back with two agents blocked, nine needing attention, and 19 that could not be established because their permissions had no labels. Four are clear, and twelve added late in the month have never been assessed. Nobody reads the four clear agents as a fleet in good order, because the screen shows them as four of 46.
The actions queue puts the two blocked agents first. The security lead blocks the invoice matcher while its owner investigates, and the confirmation states that its session in Aribot ends and that its sessions elsewhere need ending by hand, since sign-out signals are not set up yet. The decision and its reason go to the record.
Week four: blocking
The report writer's team uses the scope designer to remove ticket closure from its request. The would-be-blocked list for the operations cohort now holds only calls the team wants refused, so the platform team moves the switch to blocking. In the next audit the compliance lead exports the fleet, the assessment and the record for the month, and traces the blocked export back to the permission that allowed it to be attempted.
How it maps to the frameworks you report on
Agent governance produces evidence. Whether that evidence satisfies a requirement is a judgement for your own people and your auditors, and nothing here is legal advice.
- EU AI Act
- Supports the human-oversight and record-keeping duties the Act places on providers and deployers: a person can stop or narrow an agent, and every decision is kept. The EU AI Act readiness page explains how this feeds each system's dossier.
- NIST AI RMF
- The fleet and its owners support Govern and Map. The assessment and the activity feed support Measure. Watch only, blocking and the actions queue support Manage.
- ISO/IEC 42001
- An AI management system needs defined responsibilities, monitoring of AI in operation and retained records. The hub gives each a screen and an export.
- ISO 27001 and SOC 2
- Agents are identities. Least access, changes with a recorded reason, and a log that can be checked map to the access-control and logging controls auditors already test.
- OWASP
- The OWASP Top 10 for LLM applications names excessive agency as a risk. Sizing each agent's permissions to its task and stopping calls outside them answers it with evidence.
See EU AI Act readiness for the conformity dossier, and discovery and remediation for how findings about agents become fixes and tickets.
Where it sits in Ayurak
Free and online. It shows where your policies and processes for AI stand against the EU AI Act, the NIST AI RMF and related frameworks, including how you oversee agents.
Governs the agents that are running: the fleet, their access, every call and the record. Shadow AI discovery finds the AI nobody registered.
A detailed assessment with Ayurak's team, each answer backed by evidence, much of which Aribot already holds. Assessment templates by Aristiun.
Questions teams ask
- Will turning this on break our agents?
- Start in watch only. Every call is checked and recorded, calls that would be refused are marked would be blocked, and nothing is stopped. Most teams stay in watch only until the would-be-blocked list contains only calls they want refused, then switch to blocking.
- Which agents does it cover?
- Any agent or assistant that reaches your systems through Aribot: your own agents, agent frameworks your teams run, and assistants such as Claude, ChatGPT or Gemini connected over MCP. AI that never touches Aribot is the job of shadow AI discovery and the readiness self-assessment.
- What does an agent need to be assessed properly?
- Permissions with labels, access that was issued through Aribot, and a threat model for the system it works in. If any of these is missing the verdict says could not be established, and the assessment page tells you which one to add.
- Why keep never assessed, could not be established and clear apart?
- Because an empty result is the easiest thing to misread. A fleet where most agents could not be checked would look clean if those agents were counted as clear. Aribot shows each state with its own word and shape, and always shows how many agents were assessed out of how many exist.
- What happens when we block an agent?
- It is cut back to its minimum permissions and its session is cleared, so its next call through Aribot is refused. Sessions it holds in other systems end only if sign-out signals to your identity provider are set up. The confirmation tells you this before you apply it, and the decision goes to the audit record.
- Can one rule govern many agents?
- Yes. Agents are grouped in cohorts, for example by provider, model or deployment, and one policy can govern a whole cohort. A block or suspension applies on the agent's next action across the fleet.
- What happens if our licence lapses?
- The hub and the gateway refuse to act without an agent governance licence. Signed-in users see a request-access screen, and agent calls are refused.
- How is this priced?
- Agent governance is priced per governed agent. The pricing page has the current figure, and Ayurak's team can walk through a fleet with you on a call.
- Where do we start?
- Take the free AI readiness self-assessment to see where policy stands, start free with Aribot, connect one assistant, and look at its permissions and activity. For a fleet, book a call and we will onboard it with you in watch only.
Where you will find it once signed in
Demos and related pages
The standalone product page for governing AI agents in real time.
Bring your agents under governance, step by step.
Try watch only and blocking on illustrative agent calls.
Granted authority beside the authority used.
Shadow AI, agents, audit trail, cost and the EU AI Act together.
Agent governance is priced per governed agent.
Bring your first agents under governance
Start free with Aribot and connect an assistant, or book a call and onboard a fleet with Ayurak's team in watch only. The free AI readiness self-assessment covers the policy side.
