AI agent governance: the admin console checklist your enterprise customers will use

When an enterprise customer's IT and security team reviews your AI agent, they ask eight things: which agents are running, whose authority each one uses, what each may do, what is happening now, what happened before, how to switch it off, what it costs and what data it touches. Your admin console has to answer each of those on screen, for an administrator, without a support ticket. Below is the checklist we would take into that review: for each job, the question the administrator asks, why they ask it, and what the console must show.

Part of every answer is engineering: agent identities, enforcement outside the model, logging, token revocation and metering. Part is design: what the administrator sees, in what words, and what each control does when pressed. A console can be sound underneath and still fail the review because nobody can tell what "Disable" stops. This page is about the administrator's console. For the person who hands your agent a task, see our agentic UX design principles; for the person reviewing an action before it happens, see human-in-the-loop UX patterns.

The checklist at a glance

Why the administrator now reviews your agent

The platforms your customers already run treat agents as something IT manages. Microsoft Agent 365, generally available to commercial customers since 1 May 2026, gives administrators one registry for Microsoft and non-Microsoft agents, and its registry summary counts "unmanaged agents", those created or managed outside Agent 365 and its protections. ServiceNow announced AI Control Tower enhancements in May 2026, including a kill switch for agents, with general availability expected in August 2026; we found no confirmation that it has happened. Microsoft's own adoption guidance tells enterprises to apply the same policies to first-party, custom and third-party agents.

So an agent from a SaaS vendor arrives in a company whose IT team already has a vocabulary for agent controls, and a console to compare yours with. That is our inference from the documentation, not a measured trend.

Regulation adds weight for some buyers. Under the EU AI Act, a high-risk system must let the people overseeing it override its output and stop it in a safe state (Article 14). Deployers must give oversight to people with the competence, training and authority to exercise it, and keep the system's logs for at least six months (Article 26). The 2026 digital omnibus, Regulation (EU) 2026/1744, moved these high-risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I (AI Act explorer). In our judgement, few agent features in B2B SaaS will be classed as high-risk, so treat the Act as a reason some customers will ask harder questions, not as the reason to build.

1. Inventory

The question. "Which of your agents are running in our account, who switched each one on, and what can each one reach?"

Why they ask. An agent nobody knows about cannot be governed. Microsoft's registry shows how many agents have no owner, which happens when the account of the person who created a shared agent is deleted, and lets administrators block or delete them from that view (Microsoft). ServiceNow's AI Control Tower marks each AI asset as managed or unmanaged, finds duplicates that do the same job and imports agents from other platforms through connectors (ServiceNow release notes).

What the console must show.

• One list of every agent, and every instance of it, active in the customer's account: name, purpose in one sentence, status (on, paused or blocked), who enabled it, which teams can use it and when it last acted.
• An owner for each agent, and a visible state when that owner leaves, so the agent does not keep running with nobody answerable for it.
• The tools and connected systems each agent can reach, linked to its permissions (section 2).
• An export and an API, so the customer's own registry can take your agents in. Microsoft's registry exports to a spreadsheet; ServiceNow discovers agents through connectors.

Engineering or design. The agent records and the API are engineering. What one row says, and how an ownerless agent looks, are design.

2. Identity and permissions

The question. "When your agent does something in our account, whose authority is it using, and can we narrow it?"

Why they ask. Two models ship today. Salesforce runs internal employee agents in the context of the signed-in user, so existing permissions apply. Customer-facing agents run as a dedicated agent user, which Salesforce advises creating so that it starts with minimal access, then granting only the permissions required (Salesforce). Microsoft Entra Agent ID gives agents their own identities, so their operations can be told apart from a person's, and lets an agent act either with its own rights or with rights a user delegates; for agents built in Copilot Studio, it records the user who created the agent as its sponsor (Microsoft). A draft concept paper from NIST's National Cybersecurity Center of Excellence lists the open questions: how to handle "on behalf of" delegation, and how to bind an agent's identity to a human identity for human-in-the-loop authorisations (NIST NCCoE draft, February 2026).

What the console must show.

• For each action, which model applies: the agent acts as the person who started it, and so within their permissions, or as its own identity with its own scopes.
• The scopes in the customer's words, such as "can read invoices; can draft emails but not send them", not only OAuth scope strings.
• Who granted each scope, and when. Microsoft's install flow has the administrator review the agent's requested permissions and grant consent (Microsoft); Linear asks at installation which teams the agent may reach (Linear).
• Separate roles for who may use the agent, who may configure it and who may approve its actions. In Linear, agents cannot sign in, reach admin functions or manage users. Your agent should not be able to grant itself anything either.
• Provisioning and removal through the customer's identity provider where they use one. NIST's paper names SCIM as one way to create, update and revoke agent identities across systems.

Engineering or design. Identity infrastructure, token scopes and enforcement outside the model are engineering, and every claim the console makes must match what they enforce. The plain-language permission summary and the consent screen at installation are design.

3. Limits and policy

The question. "Before it does anything, can we decide which actions it may take, with which tools, for which teams?"

Why they ask. Salesforce lists restricting an agent's topics and limiting it to approved actions as administrator guardrails, and puts building them on the customer's side of the shared responsibility model described in section 2. GitHub lets enterprise owners set which agents are available to which organisations, and turn off MCP servers or, in the editor and command line, limit them to an approved registry (GitHub). Google Workspace applies Gemini Enterprise access to the whole organisation, an organisational unit or a group, and states that a group setting overrides an organisational unit (Google).

What the console must show.

• Every action the agent can take, each with a setting: off, needs approval or allowed. Our principles article covers how to choose the level for each action; the console is where the customer can change it.
• Scope by account, team or group, with the rule stated wherever two settings meet.
• An allowlist of the tools, connectors and outside services each agent may call.
• The effective policy for one named person: what can the agent do when Priya in finance asks? Inherited settings are where administrators get surprised, so resolve them on screen.
• In our view, new capabilities should arrive switched off, or at the most restrictive setting, with a notice to the administrator, so a product update never widens authority silently.

Engineering or design. Enforcement belongs in a policy layer the model cannot talk its way past, which is engineering. The settings matrix, the inheritance rules and the effective-policy preview are design.

4. Oversight and interruption

The question. "What is it doing right now, and can we stop one run without switching everything off?"

Why they ask. GitHub's enterprise Agents page lists and filters agent sessions from the last 24 hours (GitHub). Linear's guidelines ask agents to show whether they are thinking, waiting for input, executing or finished, and to "step back, immediately" when asked to disengage (Linear). For high-risk systems, Article 26 expects the people given oversight to have the authority to act on what they see.

What the console must show.

• Live and recent runs across the account: the agent, who started the run, its current state, the objects touched so far and any step waiting for approval.
• A stop for a single run and a pause for one agent in one team, with the effect stated before the click: whether a step already sent will finish, and what state the work is left in.
• The approval queue for actions set to "needs approval": who may approve which actions, and how long a request waits before it expires.
• Who corrected the agent, and why. In our BuildTwin work, the review of AI quality checks mapped three roles (the detailer who made the drawing, the quality engineer who reviewed it and the approver who moved it on), and an override needed a corrected state and a reason. That case is a product model, not a shipped outcome, and its AI checks drawings rather than acting in other systems. It shows the record an administrator needs, not an agent console.

Engineering or design. Durable run state and execution that can be interrupted are engineering. The run list, the words on the stop control and the account of what stopping left behind are design.

5. Audit and export

The question. "Six months from now, can we prove what the agent did, for whom and with whose approval, from our own security tools?"

Why they ask. GitHub's agent audit events carry a field marking the actor as an agent, the ID of the session that produced the event and the person who started it; administrators can filter 180 days of agent activity (GitHub). Streaming Copilot agent session activity to the customer's own log destination is in public preview (GitHub). Article 26 asks deployers of high-risk systems to keep logs for at least six months. NIST's concept paper asks how agents can log their actions and intent in a tamper-proof, verifiable way, bound back to a human authorisation.

What the console must show.

• Every agent action as an event: marked as the agent's, the person it acted for, the run it belonged to, the object and the change, and the approval or policy that allowed it.
• Changes to the agent itself: who widened a permission, enabled a tool or turned an approval off. ServiceNow's audit logs capture configuration changes to data, approvals and model providers.
• Human overrides and rejections, with their reasons, kept beside what the agent proposed.
• One run readable from start to finish, for the reviewer who has to explain an incident.
• Export by API and streaming to the customer's log platform, with the retention period shown and, where possible, set by the customer.

Engineering or design. The event schema, its integrity and the streaming are engineering. What a reviewer who is not an engineer sees when reading one run, and filters such as "actor is an agent", are design.

6. The switch-off

The question. "If it misbehaves at two in the morning, how do we stop it everywhere, how fast, and what happens to work already under way?"

Why they ask. ServiceNow's release notes describe a kill switch that deactivates and reinstates agents on named platforms (AWS Bedrock, AWS Bedrock AgentCore and ServiceNow's own agents, with limited support for Google Vertex AI) and can revoke agent session tokens through Okta. A later patch added containment from an AI asset's Overview tab and let an AI Security Operator role deactivate an agent without full steward access (ServiceNow release notes). Its May 2026 announcement expected general availability of these enhancements in August 2026. Microsoft lets administrators block an agent for the whole organisation, or delete it with 30 days in which to restore it (Microsoft).

The limits are in the detail, and they are what a reviewer will ask about. Blocking a Microsoft agent built in SharePoint or Foundry removes it only from Copilot Chat. Google says a change to Gemini Enterprise access can take up to 24 hours, and that switching Gemini off in Workspace Studio stops existing flows that use AI steps (Google). GitHub notes that restricting its own agent does not disable third-party agents.

What the console must show.

• A switch at three levels: the whole account, one agent and one run.
• A role allowed to press it that is narrower than full administrator, so the person on call can contain an agent without being able to reconfigure it.
• Before the click, in plain words: what stops (new runs, runs in progress, scheduled runs, connections to other systems), what does not, and when it takes effect.
• After the click: what was in progress, what was left half done and which outside credentials were revoked.
• A way back: what reinstating restores, and a record of who switched it off and on.

Engineering or design. Revoking tokens and propagating the block across services is engineering, and its timing sets what the screen can honestly promise. The statement of scope, the confirmation and the state shown afterwards are design.

7. Cost

The question. "What is the agent costing us, by team, and can we cap it before the invoice arrives?"

Why they ask. GitHub lets enterprises set budgets for the enterprise, an organisation, a repository or a cost centre, with alerts at 75, 90 and 100 per cent of the budget and an option to stop usage at the limit instead of only sending an email; one bundled budget covers its cloud agent (GitHub). ServiceNow's AI Control Tower tracks the costs of AI projects. Microsoft's adoption guidance tells enterprises to allocate agent costs by department and to alert as spending nears a threshold.

What the console must show.

• Usage in the unit you bill (actions, runs or credits), by agent, team and user, against the customer's plan.
• Caps per account and per team, with a choice the customer makes: stop at the cap, or alert and continue.
• What a run does when it reaches the cap: finish the current step, stop cleanly or ask. A cap that cuts a run off mid-step is a switch-off without warning.
• An estimate before a large or scheduled run, where the agent can know its size in advance.

Engineering or design. Metering and enforcing the cap are engineering. Units people recognise, the behaviour at the cap and the estimate are design.

8. Data

The question. "What does it read, where is that sent, how long is it kept, and is it used to train anything?"

Why they ask. Salesforce says its Trust Layer intercepts prompts and responses between the customer's org and the language models, and that third-party model providers do not retain them or train on the customer's data. Its setup guide warns that stored agent session data can contain personally identifying, health and payment card information, recommends dynamic data masking and data-space permissions so that only authorised users can query it, and notes that turning off Agentforce does not automatically turn off that data collection (Salesforce). Microsoft's adoption guidance asks for retention periods for logs, memory and training data, and for data residency covering each agent's sources, runtime and outputs.

What the console must show.

• For each agent, the data it can read and the systems it can write to.
• The model providers and other processors that receive data, and where they run.
• Retention for prompts, outputs, memory and logs, which of those the customer can change, and how deletion works.
• Who can read the agent's logs, because the log now holds the sensitive data the agent saw.
• A plain statement on whether customer data trains any model.
• Which settings switch off with the agent and which keep running.

Engineering or design. Data pipelines, residency and retention jobs are engineering. A data summary per agent, and defaults the customer would choose if asked, are design.

Taking the list into a security review

Mark each item as shipped, planned or missing, and bring the screen rather than the roadmap. Then run three checks before the meeting:

1. Press the switch-off on a test account and read what the console says stopped. If the answer needs an engineer, the screen is not finished.
2. Read one real run in the audit view as the customer's reviewer would: who asked, what the agent did, what approved it, what changed.
3. Compare every claim on screen with what the system enforces. "Read-only" on the console has to be read-only in the token.

If you are starting from little, our judgement is to build inventory, the switch-off and the audit trail first, because they answer whether the customer can see the agent and stop it. Per-action policy and cost caps come next.

The administrator's console is where an agent's boundaries meet your customer's IT team. Our AI copilot and agent UX work defines what an agent may know, propose, prepare and do, then designs the planning, evidence, permission, progress, interruption and recovery around that boundary. Identity, logging and security sign-off stay with your engineers and your customer's specialists.