Agentic AI changes the control problem because a model can act through tools, identities and delegated permissions. A production control set therefore needs to govern each consequential execution, not only approve the system at launch.
Observed facts: autonomy moves risk into the execution path
Agentic AI is not controlled merely because its model, prompt and intended workflow were reviewed before deployment. The operational difference is that an agent can select tools, retrieve data and perform multistep actions after the run begins. NIST's February 2026 identity and authorization concept paper focuses on identification, authorization, auditing and non-repudiation for software agents, including controls for prompt-injection risks [1]. NIST's May analysis of public responses on agent security found broad agreement that familiar cybersecurity practices remain relevant but require adaptation for agent systems [2].
Government guidance is converging on the same execution concern. Singapore's Model AI Governance Framework for Agentic AI describes governance around bounded autonomy, meaningful human accountability and controls across the agent lifecycle [3]. Joint guidance published through New Zealand's National Cyber Security Centre warns adopters about risks including privilege creep, design or configuration weaknesses, unpredictable behaviour and failures that can cascade across connected systems [4]. These documents do not create one universal technical standard. They do establish that production assurance must address what the agent can do while operating, not only what its designers intended.
Observed facts: an agent needs attributable authority
The first production boundary is identity. If several agents act through a shared service account or inherit a broad human credential, an operator may struggle to distinguish which agent requested an action, whose authority it used and which permissions were effective at that moment. Microsoft's July 2026 least-privilege pattern recommends a unique dedicated agent identity with a named owner, documented purpose, approved data access, reviewed tool dependencies and logs that capture identity, role, scope, action, resource, correlation ID and any on-behalf-of user [5]. Its Agent ID documentation also describes separate agent identities in audit and sign-in records [6].
Identity alone is not authorization. A recognisable agent can still hold excessive or stale access. The control question is therefore specific: which agent may invoke which tool, against which resource, for which purpose, for how long and under whose delegated authority? Short-lived credentials, narrow resource audiences, deny-by-default tool registration and tested revocation reduce the distance between approved purpose and executable power. This is ordinary access-control discipline applied to a new class of software actor, rather than a claim that agents require an entirely separate security universe [1][5].
Observed facts: approvals must attach to actions
A blanket human approval to deploy an agent is weaker than an approval gate placed immediately before a consequential action. Current agent runtimes already expose patterns for pausing on selected tool calls, reviewing parsed parameters and resuming or rejecting the run. The OpenAI Agents SDK, for example, supports per-tool approval rules and tool-input guardrails that can be run before and again after an approval interruption [7]. This is implementation evidence, not proof that any one framework provides complete governance.
The useful design pattern is risk-tiered execution. Read-only retrieval from an approved source may proceed automatically. A reversible internal update may operate within a capped scope. External messages, payments, deletions, privilege changes or production releases can require action-specific approval using the exact target and parameters that will execute. The gate should expire if the action changes materially. Otherwise a reviewer may approve a benign plan while the runtime later submits a different recipient, amount, command or object. Approval evidence should therefore bind the actor, proposed action, resource, parameters, approver and decision time.
Oakhampton inference: build an execution evidence chain
Oakhampton inference: commercially useful agent governance should be tested as an evidence chain rather than a policy inventory. For every material run, an operator should be able to reconstruct the request, initiating user or event, agent identity, effective permissions, tools selected, approval decisions, external side effects, outputs, exceptions and final state. OpenTelemetry's developing generative-AI conventions include operations such as agent invocation and tool execution, while warning that recorded tool arguments and results may contain sensitive information [8]. That supports structured observability, but it also means evidence collection needs redaction, access control and retention rules.
A practical control set can be organised into four linked records: an identity register naming the agent and owner; an authority policy defining tools, resources, limits and prohibited actions; an execution trace connecting each decision and tool call; and a side-effect receipt proving what changed in the target system. Reconciliation matters because a successful model response does not prove that an email was sent, a record was updated or a payment was rejected. The target system's receipt or directly observed state should close the workflow. This approach also makes incident response more bounded: disable the agent identity, revoke credentials, quarantine its tools and identify affected actions from correlated records [5][6][8].
Remaining uncertainty: standards and coverage are still uneven
The remaining uncertainty is not whether production controls are needed; it is how consistently platforms will expose them and how interoperable the evidence will become. NIST's initiative and concept work are still developing, OpenTelemetry labels parts of its generative-AI semantic conventions as development-stage, and product-specific approval or identity features do not automatically cover every hosted tool, API-key path, handoff or downstream system [1][2][8]. Organisations should therefore verify actual enforcement rather than infer it from a platform feature name.
The no-regret next step is a bounded runtime test before broader autonomy. Give one agent a unique identity and minimal tool set; define one consequential action that must pause; attempt an out-of-scope resource access; revoke the agent during a test run; and confirm that the logs and target-system receipts reconstruct the result without exposing unnecessary content. Expand only when those controls work under failure, retry and changed-input conditions. The objective is not zero autonomy. It is autonomy whose authority, actions and outcomes remain attributable when the production path departs from the happy-path demonstration [3][4][5].
Sources
- Accelerating the Adoption of Software and AI Agent Identity and Authorization Concept PaperNIST National Cybersecurity Center of Excellence · 5 February 2026
- Summary Analysis of Responses to the Request for Information Regarding Security Considerations for AI AgentsNational Institute of Standards and Technology · 18 May 2026
- Model AI Governance Framework for Agentic AIInfocomm Media Development Authority of Singapore · 22 January 2026
- Careful Adoption of Agentic AI ServicesNew Zealand National Cyber Security Centre · 1 May 2026
- Least privilege for AI agents (agentic identities and RBAC)Microsoft Learn · 15 July 2026
- Agent identities, service principals, and applicationsMicrosoft Learn · 30 April 2026
- Human-in-the-loop approvals in the OpenAI Agents SDKOpenAI Agents SDK
- Generative AI semantic convention attributesOpenTelemetry