Only let an AI agent act after a separate verification check
The production decision: separate proposing from executing
Choose an action boundary between the agent and every system that makes changes. The agent first specifies what it wants to do, for what purpose, with which data, and on behalf of which user or workflow. The control layer then decides whether to execute, deny, or escalate. This does not mean a prompt is worthless; it is a design choice for the point at which a proposal becomes a real system action. The NIST concept paper frames the issue around agents that autonomously perform tasks and gain access to diverse datasets, tools, and applications; it identifies identification and authorization controls as a way to mitigate risks. The supplied MCP publication also identifies scoped authorization, provenance tracking, input/output checks, and inline policy enforcement as proposed controls. Use these passages as guidance for the boundary, not as proof that one specific architecture eliminates all risks.
What the control layer must be able to assess for each action
Have the layer answer at least four questions: may this actor perform this action, does the action fit the current context, does it affect a prohibited or sensitive resource, and does the risk require a human decision? Authorization can be based on attributes: the NIST ABAC publication defines ABAC as a logical access control methodology in which authorization for operations is determined through evaluation. In an agent flow, relevant attributes may include the role, tenant, tool, data class, action, and approval status. Record hard boundaries as explicit rules, such as prohibited actions, permitted destinations, and mandatory escalations. Add contextual assessment only where the meaning of the proposed action genuinely matters. The ACP study describes an admission-control protocol with static risk scores and state information about execution traces; the described test is a specific experiment, not a general performance or security promise for your environment.
Make the boundary workable with an action card
Use an action card as a decision register for a single agent workflow. For each action, record: owner, actor or identity, purpose, target resource, data used, required attributes, hard policy, risk level, outcome (allow, deny, or escalate), and log location. The practical tool is: “For each proposed agent action, record the purpose, actor, resource, required permissions, policy outcome, risk level, and owner of the escalation.” Start with the action most likely to directly affect an external system or customer data; this creates a testable boundary without immediately redesigning the entire agent stack. The limitation is: “This approach is an architecture and governance pattern, not a guarantee that an agent will not encounter an error, abuse, or unexpected context.” This matters because source passages describe controls and risks, but do not provide individual legal, financial, or professional advice and do not replace a complete implementation assessment for your organization.
Further reading
Sources
- [2603.18829] Agent Control Protocol: Admission Control for Agent Actions
- [Concept Paper] Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization | CSRC
- Guide to Attribute Based Access Control (ABAC) Definition and Considerations | NIST
- [2511.20920] Securing the Model Context Protocol (MCP): Risks, Controls, and Governance
- Source video
- Source video (historical reference)
