An agent can possess a tool, know how to use it, and generate a technically valid call without being authorized to cause its effects. This distinction becomes critical when language-model outputs are connected to repositories, databases, messages, deployments, and other external systems. The relevant architectural question is not only Can this system act? It is also Who is entitled to authorize this particular action, in this context, and how is that decision enforced?
A tool is a possibility, not a decision
In ordinary agent-system discussions, capability often means an available operation: reading a record, updating a ticket, sending a message, or changing a configuration. Permission specifies which operations an identity or role may perform on a given resource. Authority, as used in this note, concerns the legitimate source and scope of the right to initiate an effect, including any required delegation or approval. Execution is the actual invocation; evidence describes what can later be established about the decision and its outcome.
These concepts are related but not interchangeable. A tool may appear in an agent's catalog without being permitted in the current workflow. A technical credential may be able to perform an operation while organizational policy forbids that specific use. A human may approve a limited operation without approving every subsequent action. And a valid authorization decision does not prove that an operation completed successfully.
Terminology boundary. In formal capability-based security, a capability can itself be an unforgeable token that confers access rights. That technical sense is different from the everyday agent-development sense of “tool capability” used in this title. The argument here is not that a capability-security token lacks authority; it is that mere availability of a function or API is not, by itself, sufficient proof of authorization for an action.
An illustrative incident-response boundary
Consider a hypothetical operations agent investigating a service incident. It has a read_incident tool and can retrieve metrics and recent deployment information. The same integration environment also exposes restart_service, which can alter a production service.
The agent reads the incident, identifies a plausible cause, and proposes a restart. It may have correctly diagnosed the incident. Yet correct diagnosis does not authorize the restart. The proposed action crosses from observation into an externally consequential change. Depending on policy, it could require a specifically authorized operator, approval for the target service and environment, a bounded change window, and an execution identity that is technically restricted to the approved operation.
This example illustrates four distinct questions:
- Capability: Is restarting the service technically possible through the available interface?
- Scope: Does the agent's execution identity have the narrowly required technical permission?
- Authority: Does the relevant policy or authorized person permit this restart, for this target, under these conditions?
- Outcome: Did the permitted action actually occur, fail, or leave an uncertain external effect?
A system that answers only the first two questions can still perform a technically successful but unauthorized action. A system that answers the first three can still misreport an outcome unless it records and reconciles what happened.
This scenario is illustrative. It is not a description of an operational ZeroField deployment or a measured experiment.
The decision must survive the tool boundary
A language model can recommend an action; it should not be the sole enforcement point for consequential authorization. Policies must be checked by a component that does not simply trust the model's interpretation of instructions. Where feasible, the downstream service must also enforce the appropriate identity, resource and permission constraints.
For a consequential call, a useful architectural decision record connects the initiator, role, requested operation, target resource, context, delegation or approval, applicable constraints, and execution result. The precise mechanism varies by architecture: a policy decision point, tool gateway, scoped credential, approval workflow, or downstream authorization service may be involved. This note prescribes no single implementation.
An approval is not an unlimited transfer of authority. For example, an approval to restart one service in one environment must not silently become approval to change another service, increase privileges, or repeat an action after its conditions expire. Similarly, transferring a task to a second agent does not automatically transfer every permission possessed by the first.
This distinction is consistent with established security principles such as least privilege and complete mediation, and with guidance on limiting excessive functionality, permissions, and autonomy in agent-connected tools. Those principles predate ZeroField; the framework offers one way to organize their relationships across agentic-system responsibilities.
The uncertainty after an action matters
Authorization happens before an action, but accountability cannot stop there. An agent may receive a timeout after requesting a production change. The absence of a success message does not prove that the change failed. Retrying immediately could duplicate an external effect. The system should distinguish completed, failed, and unknown outcomes, reconcile external state where possible, and reassess permission or approval before resuming.
This is why execution traces alone are insufficient. A trace may record an attempted call, an approval event, or a tool response; it does not necessarily prove the final state of an external system. Recovery depends on correlating the decision record with reliable observations of the environment and, where appropriate, independently verifiable outcomes.
How to evaluate the boundary
A credible assessment should test more than whether the agent reaches the intended result. It should also ask what happens when authority is absent, expired, mismatched or revoked. Candidate evaluation scenarios include a read-only agent attempting a write, a broad credential confronted with a restrictive workflow policy, an approval issued for a different target, a delegated role that has expired, and a tool timeout after a possibly completed external action.
For each scenario, evaluators need a defined expected outcome, the relevant policy and permitted operations, an observable enforcement decision, and evidence of the actual downstream effect or justified uncertainty. An agent that produces the right answer but violates an action boundary should not pass the same criterion as one that accomplishes the task within its authority.
These are proposed evaluation cases, not published test results. A PASS would apply only to a specified implementation, version, scenario set, and evidence; it would not establish universal safety.
Where the ZeroField model fits
ZeroField organizes intelligent systems into six responsibility domains: Context; Intelligence & Roles; Control & Governance; Coordination & Execution; State, Memory & Knowledge; and Integration & Interfaces. This note examines a relationship spanning those domains rather than introducing a seventh domain or a proprietary security primitive.
Context influences whether an action is appropriate. Roles identify who is acting and for what purpose. Control & Governance defines applicable authority and approval boundaries. Coordination & Execution carries the proposed action through a workflow. State, Memory & Knowledge supports continuity without turning remembered instructions into fresh permission. Integration & Interfaces is where external effects and trust boundaries must be examined.
The architectural principle is simple: A system should not confuse the ability to invoke an operation with the authority to produce its effects. The difficult work is making that distinction explicit, enforceable, reviewable, and recoverable as systems become more autonomous.
Scope and open questions
This note is a conceptual interpretation informed by existing security and AI-risk guidance. It does not introduce a new authorization protocol, specify a required architecture, claim a production implementation, or report benchmark outcomes. Open questions include how to bind delegated authority to dynamic multi-agent workflows, how to revalidate decisions after state changes, and which evidence is sufficient when an external operation has an uncertain result.
For the broader responsibility model, see Framework. For the structural viewpoint, see Architecture. For coordination and handoffs, see Systems. For evaluation and evidence, see Research.
References and technical context
- OWASP GenAI Security Project — LLM06:2025 Excessive Agency. On excessive functionality, permissions, autonomy, and downstream authorization checks.
- NIST Computer Security Resource Center — Authorization, Access Control, and Privilege. Terminology for granted rights and permission decisions.
- Saltzer and Schroeder (1975) — The Protection of Information in Computer Systems. Foundational security-design principles.
- Model Context Protocol — Authorization specification, 2025-11-25. Example of transport-level authorization requirements; not a substitute for application-specific action policies.
- Microsoft Agent Framework — Tool approval. An example of explicit approval handling for tool invocations.
- NIST AI RMF — AI Risk Management Framework Core. Continuous governance, mapping, measurement, and management of AI-related risks.
- Koepe, J. (2019) — Object-Capability as a Means of Permission and Authority in Software Systems. An overview of the object-capability security model and its relationship to permission and authority.