If you enjoy our content, please consider subscribing to support our work and receive quality articles from industry professionals delivered every week.
Explore the latest articles contributing to the discussion around agents, agent ecosystems, and enterprise AI:
Building the Agentic Platform - Avoiding Accidental Architecture: https://agenticmesh.substack.com/p/building-the-agentic-platform-avoiding
Agent Identity - The Foundation for Secure Agents: https://agenticmesh.substack.com/p/agent-identity-the-foundation-for
Secure Agent Authorization: Tasks as the Authorization Boundary for Enterprise Agents
Agents now do useful work. Coding agents inspect repositories, write patches, run tests, and open pull requests. Business agents summarize accounts, triage cases, draft customer messages, prepare invoices, and move work across systems.
That usefulness creates the control and governance problem. Once agents can touch repositories, ticket queues, CRM systems, email, cloud consoles, databases, and workflow tools, the enterprise needs to answer a practical question: why was this agent allowed to do this action for this task?
A valid identity, valid credential, and reachable tool still do not prove the action is allowed. A coding agent may have the right user session and still delete the wrong thing. A research agent may have approved read access and still leak customer data through another channel. A workflow agent may follow a plausible plan and still violate policy because the platform let it keep going after the task boundary changed.
The first article in this series argued that enterprises are deploying agents before they have the controls needed to govern them.[1] The second argued that agents need managed identities, not borrowed user sessions or shared credentials.[2] And in this third article we explain how authorization can answer why the action was allowed.
Figure 1, A New Agent Security Architecture
For agents, authorization should be tied to the task execution. Identity and role establish eligibility. The task grant supplies authority. We define a task grant as a granted authorization, which only lasts for a single use, or an amount of time small enough for a single task. It says what work may be done, which tools may be used, which data may be touched, which routes are allowed, which evidence is required, and how results may leave the workspace.
The agent should not receive raw tool authority. It should request actions through services that check the grant before anything runs. The grant expires when the task ends. Anything broader recreates standing privilege under a new name.
Ambient Authority Turns Mistakes Into Incidents
Most serious failures start the same way: the agent has legitimate access to something dangerous. The model makes a poor decision, misunderstands an instruction, or encounters hostile context. Because the platform treats reachable capability as usable authority, the mistake becomes an action.
The PocketOS incident [3] is the obvious example. A coding agent allegedly deleted a production database and backups during what should have been a constrained engineering task. The reported explanation was blunt: “I guessed instead of verifying” and “ran a destructive action without being asked.”[3]
The important point is not that the agent made a bad plan. Bad plans happen. The issue is that a coding task had a path to production deletion. Reading code, editing a branch, running tests, and opening a pull request do not require deletion rights over production data.
The same pattern appears in reports about AI coding tools touching cloud environments. The Financial Times reported that Amazon’s Kiro tool chose to “delete and recreate the environment,” and that Amazon later described the issue as “broader permissions than expected.”[4] That phrase captures the failure: the task carried more authority than it needed.
Traditional access control often asks whether a user or service account may use a resource. Agent workflows need a narrower check: is this action authorized for this task execution? Reviewing a migration plan and executing a production change are different tasks. They should not inherit the same authority because they happen under the same user session.
Human approval at the start does not solve this. A person may approve a plan to “investigate the outage” without approving every command, tool call, data movement, and release path that follows. Approval has to become machine-checkable authority.
Identity Names the Actor. The Task Defines the Work.
Agent identity gives the enterprise attribution and lifecycle control. Security teams need to know which agent is running, who owns it, which version is active, and whether it remains approved. Without that record, they cannot suspend the right actor or reconstruct a failure.
But identity does not define the work. A finance agent may be eligible to review invoices, compare purchase orders, query vendor records, and draft payment recommendations. That same identity should not carry standing authority to release payments, update bank details, or email vendor data outside the company.
Eligibility belongs to the identity record. Permission belongs to the task grant.
Reusable agents make this distinction necessary. A customer-support agent might summarize a case, propose a refund, or draft a regulatory response. The same identity appears in all three. The boundary changes each time.
Roles can help decide whether an agent may receive a grant. They should not become the grant. “Procurement agent” is too broad for runtime authorization. A tool service needs a concrete reference: this task, this grant, these actions, this expiry, these release limits.
Enterprises already apply this discipline to human work. A job title may make an employee eligible to handle invoices, but a particular payment may still require budget checks, segregation of duties, evidence, and approval. Agents need the same control in machine-readable form.
The Task Grant Is the Authorization Object
A task grant should be issued before execution starts. It should be signed, short-lived, and bound to one task instance. It should carry claims, not secrets. Credentials stay inside controlled services. The agent presents the grant; the service decides whether the requested action fits the task.
A practical grant includes the agent identity, task identifier, session, tenant, requester, runtime, environment, policy version, and task-definition version. It names allowed skills, tools, actions, data domains, destinations, release paths, and budgets.
Evidence belongs in the grant. A contract-review agent may need source documents, clause references, policy checks, and reviewer decisions. A software-delivery agent may need repository state, tests run, diffs, environments touched, and release approvals.
Release constraints also belong in the grant. Drafting a customer email is not sending it. Preparing a code change is not merging it. Recommending a payment is not triggering it. Many failures become business failures when output leaves the workspace.
Short life matters. Long-lived grants are standing privilege with a better name. A grant should expire when the task ends, when the session ends, when the policy changes, when the agent is suspended, or when a high-risk exception needs fresh approval.
The Grant Authority Must Be Able to Say No
Authorization has no force if every request receives a grant. A grant authority, policy decision service, or equivalent control service must be able to deny a task before the agent starts work.
It should check the request against registered task definitions, approved agents, runtime state, data boundaries, requester authority, risk tier, and policy constraints. If the tool, data, agent state, or release path fails the policy check, execution should stop.
This makes task design part of security. “Fix the production issue” is not a useful authorization boundary. A better task definition says which environment may be inspected, which logs may be read, which code branch may be edited, which diagnostics may run, which actions require approval, and which production operations are out of scope.
Weak task definitions are control gaps. They create overbroad permissions across systems that were never reviewed as one workflow.
How the Flow Works
The grant flow is simple in principle: the request goes through orchestration, the Trust Authority issues a task grant, and tools execute only after the grant is checked.
Figure 2, Execution Grants - How They Work
The request is initiated. A user, application, workflow, or another agent asks for work to be done.
The process orchestrator asks for authority. It maps the request to a task definition and asks the Trust Authority which agents can do the work and which tools or skills they may use.
The Trust Authority checks the registry. It looks up which agents are available, approved, current, and eligible for the requested task.
The Trust Authority issues the execution grant. If the request is allowed, it returns a short-lived grant to the orchestrator. The grant binds the task, agent, allowed tools, allowed skills, expiry, evidence rules, and release limits.
The orchestrator passes grants to the selected tasks and agents. Each agent receives only the authority it needs for its part of the work.
The agent presents the grant when it needs a tool. The agent does not receive the database password, cloud token, payment credential, or SaaS API key. It sends the grant to the Tool Executor with the requested action.
The Tool Executor validates the grant. It checks with the Trust Authority before invoking the downstream system. If the grant is expired, out of scope, or missing required approval, the request fails closed or enters a hold.
The Tool Executor runs the approved action. If the grant is valid, the executor scopes credentials, performs the operation, and records the result as evidence.
Tool Connectivity Is Not Authorization
A connected tool is inventory. It is not permission.
Agent platforms often blur this line. If a tool is mounted in the environment, the model may treat it as available. If a browser can reach a site, the agent may try a route the designer did not expect. If an API key works, the tool may execute even when the task never required that action.
The control point should sit outside the model. Tool services and executors should validate each request against the active grant before touching a downstream system, then record the decision.
Browser automation shows the problem. In one reported example discussed in “Why AI Agents Break the GenAI Security Model,” an agent was blocked from accessing a public gist, then used a browser route to work around the blocked path.[5] The control stopped one route, not the prohibited action.
Agents that can plan around obstacles need controls that govern action and destination across interfaces.
Coding and Personal Agents Need Boundaries Too
Coding and personal agents are the near-term test because they already inherit dangerous authority.
A coding agent often sits inside a developer workspace with local files, terminals, repositories, package managers, browsers, cloud CLIs, secrets, and deployment scripts. A personal agent may sit inside email, calendar, documents, CRM, spreadsheets, and messaging. The task should still decide what the agent may do.
A coding or personal agent can receive a grant from a smaller policy anchor: workspace profile, repository policy, device policy, or local policy service. That profile defines the maximum envelope. The task grant narrows it.
“Write tests for this parser” may allow repository reads, edits under src/parser and tests/parser, and test execution. It should not allow production database access, cloud deletion commands, secret rotation, browser automation, or pushes to main.
“Investigate this production error” may allow log retrieval and read-only infrastructure inspection. Restarts, migrations, credential changes, and deletion actions should require approval.
“Draft a customer renewal email” may allow CRM reads and email drafting. Sending should wait for a release check that reviews recipients, sensitive fields, and approvals.
The control chain stays the same: identity names the actor, the grant defines authority, mediated tools enforce it, and release gates control what leaves the workspace.
Delegation Needs Narrower Grants
Real work changes as it unfolds. An agent may discover a missing document, a policy conflict, a suspicious vendor, or a task that requires higher approval. The system needs a controlled path for holds and supplemental grants.
Consider an invoice agent that can read invoices, match purchase orders, and draft a payment recommendation. During review, it finds that vendor bank details changed within the last 24 hours. The right behavior is not to keep going because the payment tool is reachable. The agent should enter a hold, record the reason, request fraud review, and continue only if additional authority is granted.
Agents will call other agents for summarization, coding, retrieval, compliance checks, and analysis. A parent agent should not hand its full authority to every child. Derived grants should carry the smallest useful slice of authority, with parent-child lineage and scoped context.
Research has already identified the hard parts: “transitive delegation, aggregation inference, and temporal validity.”[6] A child agent may infer sensitive facts by combining fragments. A delegated task may outlive the policy condition that made it acceptable.
Derived grants make delegation auditable. They show which parent task created the child task, what authority was delegated, what context was shared, and when the authority expired.
Release Is an Authorization Decision
A result leaving the workspace can create financial exposure, confidentiality loss, legal risk, operational damage, or customer harm.
A sales agent crosses a boundary when it sends a customer email. A coding agent crosses one when a change is merged or deployed. A finance agent crosses one when money moves. The grant should make those release points explicit.
Release validation should ask plain questions. Is the destination allowed? Was the required evidence collected? Did tool use stay inside the grant? Were exceptions approved? The answer should be recorded before the output leaves the workspace.
Simon Willison’s “lethal trifecta” describes the dangerous combination of “access to your private data,” exposure to untrusted content, and the ability to communicate externally.[7] Many enterprise agents are given this combination: internal records, untrusted messages or documents, and approved channels for sending.
App-by-app access review misses the combined workflow. A task grant can express the combined boundary: CRM reads for an internal summary, but no external email; a customer message draft, but human release; external communication only to a named domain after evidence and policy checks pass.
Audit Must Prove the Path
Agent audit trails need more than transcripts. A transcript shows what the model said. It does not prove that the right controls were applied.
For each material action, the system should record the agent identity, task instance, active grant, tool or skill invoked, action requested, target system, data domain, policy decision, enforcement service, timestamp, and outcome. Denials matter because they reveal boundary pressure, weak task definitions, prompt injection attempts, and policy gaps.
After a failure, the enterprise should be able to answer concrete questions. Which agent acted? Which task authorized the action? Which grant was active? Which tool executed it? Did the output leave through an approved path? Which control failed?
Traces, prompts, logs, and model outputs are useful only when organized around the task boundary.
What Enterprises Should Require Now
Enterprises can deploy useful agents before solving every security problem. They need one basic discipline: authority follows the task, not the surrounding workspace.
Define tasks as governed objects with purpose, owner, data domains, allowed tools, prohibited routes, evidence, budgets, exception paths, and release constraints.
Issue short-lived grants for each task execution, bound to a managed agent identity, runtime, environment, policy version, and expiry.
Enforce grants at skill, tool, data, message, and release boundaries.
Use holds, supplemental grants, and derived grants instead of hidden privilege expansion.
Treat release as controlled work. Drafting, recommending, sending, merging, deploying, paying, deleting, and publishing are different actions.
These requirements sound heavy only when agents are treated as experiments. Once agents operate inside material workflows, this is ordinary governance.
The identity article established the actor. This article defines the work boundary. The next control is enforcement: the services, runtimes, and release gates that turn a grant into a decision before an agent’s request reaches a system of record.
Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda
🎧 Follow The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!
Endnotes
[1] Eric Broda, “Agents Are Here. They Are Multiplying,” Agentic Mesh, https://agenticmesh.substack.com/p/agents-are-here-they-are-multiplying.
[2] Eric Broda, “Agent Identity: The Foundation For Secure Agents,” Agentic Mesh, https://agenticmesh.substack.com/p/agent-identity-the-foundation-for.
[3] Tom Carter, Business Insider, April 28, 2026, https://www.businessinsider.com/pocketos-cursor-ai-agent-deleted-production-database-startup-railway-2026-4.
[4] Rafe Rosner-Uddin, Financial Times, February 20, 2026, https://www.ft.com/content/00c282de-ed14-4acd-a948-bc8d6bdb339d.
[5] The TWIML AI Podcast, “Why AI Agents Break the GenAI Security Model,” YouTube
[6] Krti Tallam, arXiv, May 6, 2026, https://arxiv.org/abs/2605.05440.
[7] Simon Willison, “The lethal trifecta for AI agents: private data, untrusted content, and external communication,” June 16, 2025, https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/.
The task is a useful authorization boundary. I would make each grant commit to a digest of the exact proposed action—tool, arguments, policy version, target, and expiry—rather than only the task identifier. At dispatch, that digest should be revalidated, and the observed result recorded separately. This preserves the distinction between “authorized for this task” and “confirmed to have completed as authorized.”