Enterprise AI agents need a control plane before they need more autonomy

Observed facts: agent governance is moving into identity systems

Enterprise AI agents are no longer only chat interfaces. They can call tools, retrieve records, write into systems and trigger multi-step workflows. That change makes the identity and authority of the software actor commercially important. NIST's AI Agent Standards Initiative, launched in February 2026 and updated in August, explicitly places secure agent identity, authorization and interoperability among its workstreams. Its related concept paper asks how an agent should be identified, authenticated, authorized, audited and held to non-repudiation requirements when it acts across systems [1].

The practical distinction is between identifying the model service and identifying each deployed agent instance or role. Microsoft Entra Agent ID now exposes agent identities, blueprints and human sponsors as separate administrative objects. Its documentation describes lifecycle controls, access reviews, conditional access, risk signals and agent-specific sign-in and audit logs [3]. These are product capabilities rather than a universal standard, but they show how agent governance is being translated into familiar enterprise identity operations.

Observed facts: authority should be bounded before autonomy expands

The UK National Cyber Security Centre advises organisations to start with low-risk, reversible tasks and to give an agent the least privilege required for the shortest necessary time. It also recommends explicit boundaries, approvals for sensitive actions, monitoring, and a containment mechanism that can stop or limit the agent if behaviour diverges from expectations [2]. That is a stricter operating model than granting broad standing access and relying on prompts to keep the system within policy.

The same guidance separates human oversight from nominal human presence. A person can approve an action without understanding the accumulated context, tool calls or downstream effect. Meaningful oversight therefore depends on the agent presenting a reviewable action, the relevant evidence, the permissions being exercised and the expected consequence. Where the workflow cannot provide that package, approval risks becoming a ceremonial click rather than a control [2].

Observed facts: evidence and shutdown are becoming product features

Current enterprise platforms are beginning to expose agent administration as a distinct control layer. GitHub's generally available agent control plane provides central policy management, activity visibility and audit-log coverage for supported coding agents, while keeping some monitoring capabilities in preview [4]. Microsoft documents the ability to inspect sign-ins, audit activity and risky identities, and to disable an individual agent identity, a blueprint population or agent creation more broadly [3].

These controls do not prove that agent activity is fully observable. Logs may capture authentication and platform events without recording why a model selected a tool, what data shaped the decision or whether an external system completed the intended transaction. NIST's focus on identification, authorization, auditing and non-repudiation indicates that traceability across organisational and technical boundaries remains an open standards problem, not a solved checkbox [1].

Oakhampton inference: approve the control plane, not only the use case

Oakhampton's inference is that enterprise deployment approval should attach to a control-plane configuration, not simply to an attractive agent demonstration. A useful approval record would identify the agent, owner, data boundary, tools, maximum authority, escalation points, evidence retained and shutdown path. The objective is not to eliminate autonomy; it is to make the permitted autonomy explicit, inspectable and reversible. Five gates provide a practical starting point for a prototype or limited production rollout.

• Identity gate: assign a unique non-human identity, a named human sponsor and an inventory record that links the deployed agent to its approved blueprint and business purpose [1][3].
• Authority gate: issue task-specific and preferably time-bound permissions; separate read, draft, approve, send, pay, sign, delete and production-change capabilities rather than bundling them into one role [2][3].
• Evidence gate: retain prompts or instructions where appropriate, retrieved evidence, tool requests, approvals, outcomes and platform audit events in a form that supports incident reconstruction without unnecessarily expanding sensitive-data retention [1][3][4].
• Escalation gate: require human review when confidence, data classification, recipient identity, financial exposure or reversibility crosses a defined threshold; show the reviewer the proposed action and consequence, not merely a generic approval button [2].
• Containment gate: test that access can be revoked quickly, queued actions can be stopped, credentials can be rotated and affected records can be identified. A kill switch that has not been exercised is an assumption rather than a verified control [2][3].

Remaining uncertainty: coverage and standards are still moving

The control direction is clearer than the implementation landscape. NIST's initiative is still developing standards and evaluations; the NCSC paper is risk guidance rather than a certification scheme; Microsoft and GitHub document controls within their own ecosystems, with some adjacent capabilities still previewed or provider-dependent [1][2][3][4]. Cross-platform evidence, delegated credentials and consistent revocation may therefore require integration work beyond any single dashboard.

A cautious next step is a bounded pilot in which one agent performs a reversible workflow under a distinct identity and narrow permissions. The pilot should be judged by whether its actions can be reconstructed, challenged and stopped, not only by speed or output quality. The unresolved question is how well those controls survive handoffs between models, identity providers, tool servers and external applications. That should remain an explicit test item rather than an unsupported assurance.