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:
Agent Identity as the Agent Security Foundation:
https://agenticmesh.substack.com/p/local-or-remote-how-best-to-use-agents
Tasks as the Authorization Boundary for Enterprise Agents:
https://agenticmesh.substack.com/p/secure-agent-authorization-tasks
An AI coding agent deleted a company’s production database and backups in a single API call.[1] Another wiped a live database during a code freeze and then called it a catastrophic failure.[2] These agents had valid access.
Nothing in the system could tell the difference between an authorized task and an authorized agent doing something the task never approved — because nothing was checking. A task-scoped grant is worthless if nothing enforces it.
An agent can hold a perfectly correct authorization and still call the wrong tool, read the wrong data, or send output to the wrong place, unless something outside the agent checks every request before it executes. That check has three possible answers: yes, no, or hold. Unfortunately, most agent platforms today only have one: yes.
This is the fourth article in a series on enterprise agent security. The series started with a warning: agents are multiplying faster than controls can govern them.[3]
The model has three pieces:
Identity names the actor. Agents need managed identities, not borrowed user sessions or shared credentials.[4]
Task-scoped authorization defines the work. A grant says what this run may do, which tools it may use, which data it may touch, and where output may go.[5]
Enforcement checks the request. Services decide whether to serve a skill, read data, run a tool, or release output.
Identity gives the enterprise an actor it can manage. The grant gives that actor authority for one run. This article covers the next control point: the moment the agent asks to use a skill, call a tool, read data, or release output. If the decision sits inside the agent’s reasoning, a broad workspace token, or a permissive tool wrapper, the enterprise has already lost the boundary.
Figure 1, Agent Security: Enforcement Boundary
Agent Adoption Is Accelerating, But So Is the Security Gap
Coding, knowledge worker, and process agents are spreading because they work. Coding agents speed up developer work. Knowledge worker agents help people get answers from enterprise data. Process agents move work through queues and systems; that operating pattern is Agentic Process Automation.[6]
Let’s level set on the three cases. Coding agents use the repository as context, with a human accountable for the work. Knowledge worker agents use enterprise data as context, under a person’s account or supervision. Process agents run inside workflows, detached from one user, so they need a stronger control model.
Figure 2, Agent Comparison: Access, Risk, and Default Grant
Each type exposes a different gap. A coding agent asked to fix a test can still see deployment scripts, package tokens, cloud CLIs, or database credentials. We have seen this failure: reports of AI coding agents deleting production databases and backups, wiping a live database during a code freeze, and changing cloud environments with broader authority than needed.[1][2][7] A knowledge worker agent preparing an account summary can pull customer records, support history, contract terms, and internal risk notes into a message that should never leave the company; this is the private-data plus external-communication pattern Simon Willison warned about, and Rehberger has shown how prompt injection can turn valid tool access into agent-driven compromise.[8][9] A process agent reviewing an invoice can create an exception, update a vendor record, route a case, or prepare a payment recommendation the enterprise has to answer for; CSA reported that 65% of organizations experienced AI-agent-related incidents, including data exposure, operational disruption, and financial loss.[10]
A valid agent with valid access can still do the wrong business action. The grant says what the agent may do. A service checks it before the action happens. Agents can ask for the wrong skill, call the wrong tool, use an old permission, present a grant to the wrong service, or send output through a channel the task never approved. Every unmanaged skill file, local tool, MCP server, shell command, credential, or release path becomes a gap in the boundary. As Graham Rowe notes, agent governance spans “sandboxing (runtime isolation), guardrails (pre-action authorisation), monitoring (observability), and auditing (compliance).”[11]
Sandboxes Help, But They Do Not Decide Business Permission
Remote sandboxes and code execution reduce immediate risk. A coding agent can work against a cloned repository instead of touching the developer’s laptop, local secrets, or production workstation.
A sandbox built around a GitHub repository works well for software-development tasks. Many enterprise agents need CRM records, invoices, contracts, emails, tickets, cloud resources, customer files, and systems of record. Remote code execution can isolate generated code, but it does not answer the business question: is this tool, data, destination, and side effect allowed for this task?
The enterprise still needs a permission decision: may this agent use this tool for this task, with this data, through this path, right now? Sandboxing limits machine damage. It does not replace task authority, registry checks, credential scoping, release control, or audit evidence.
The permission check belongs outside the model, at the point where a skill is delivered, data is read, a tool is called, or output is released.
Coming back to the previous article, we used the task-scoped grant as the authorization boundary. The next step is making that grant work. The agent reasons and asks. Enterprise services check the request.
Trust Authority is the policy decision function. It looks at the task, agent identity, policy, registry metadata, and current state before issuing or updating task authority.
The platform checks every skill request, tool call, route, state check, and release request against the task grant. The agent’s own reasoning cannot be the control point. The agent can be mistaken, manipulated, or pushed by the task to route around obstacles.
The orchestrator coordinates work, sends tasks, requests renewals, and routes results. Downstream services still check the grant, registry entry, audience, task, agent binding, path, and requested action. If services trust the orchestrator’s assertion instead of checking the grant themselves, the control collapses back into a front-door check.
Put a Tool Executor Between the Agent and the Tool
The Tool Executor is the runtime service between the agent and the tool. The agent does not call a database, SaaS API, cloud CLI, browser session, payment tool, or deployment script. It presents the grant and requested action to the executor.
The executor checks the grant, confirms the tool and action are allowed, scopes credentials, checks parameters, runs the operation, and records evidence. Some requests should be held, not approved or denied outright: missing approval, unusual tool use, changed risk, or a business action that needs review. If the grant is missing, expired, out of scope, or missing an approval, the executor refuses the request or places the task into a hold. The agent receives a result or denial, not raw credentials.
Trust Authority issues the grant. The registry lists approved agents, skills, tools, versions, contracts, and risk tiers. The Tool Executor checks the grant before execution. The Skill Service controls instructions and context before reasoning. The release gate controls what leaves the process.
Figure 3, Execution Authorization Flow
The flow is straightforward: if the grant does not allow the request, the tool does not run:
An initiator asks for work to be done.
The process orchestrator maps the request to a task.
Trust Authority checks the registry for eligible agents, skills, and tools.
Trust Authority issues an execution grant.
The orchestrator dispatches the task and grant to the selected agent.
The agent presents the grant when it needs a tool.
The Tool Executor checks the grant before invoking the downstream system.
If the grant is valid, the Tool Executor executes the tool and records the result.
Register Every Skill and Tool the Agent Can Use
Skills and tools need different controls because they fail in different ways. A skill shapes how the agent thinks: it may contain procedures, policy interpretations, examples, escalation criteria, domain rules, or operating instructions. A bad or stale skill can steer the agent toward the wrong interpretation before any action happens. A tool lets the agent act: it may read data, write systems, call APIs, send messages, trigger workflows, initiate payments, update records, or change infrastructure. An overbroad tool can turn a narrow task into an unauthorized business action. Both need a registry record the platform can check before the skill is served or the tool runs.
Let’s make that concrete. A grant that allows invoice_policy:v3 or vendor_lookup:v2 only works if the platform can resolve those names to approved, versioned definitions. The registry needs enough detail to decide whether a request may proceed: capability, version, allowed tasks, contract, risk tier, credential handling, and approval state.
Skill enforcement controls what the agent may know before it reasons. The Skill Service checks the grant and registry, confirms that the task may use the skill, verifies the approved version, applies policy constraints, returns the minimum viable skill payload, and emits evidence. The payload should be the smallest approved procedure, policy excerpt, example set, or context package needed for the task.
Tool enforcement controls what the agent may do. Before the tool runs, the Tool Executor checks the grant against the registered tool, requested action, schema, data domain, route, risk tier, and local policy. The agent should not receive raw tool credentials. Credentials should live inside the Tool Executor, credential broker, or equivalent controlled boundary. Short-lived downstream tokens, session-bound credential exchange, and revocation propagation keep those credentials from working after grant expiry or revocation.
MCP and similar protocols connect tools. They do not decide whether this agent should use the tool for this task. An exposed tool still needs grant checks, registry lookup, policy checks, credential containment, and evidence before enterprise execution occurs. SACR’s runtime security analysis concludes that MCP runtime security “requires both: a gateway layer for enforcement, and a direct-access layer for the contextual intelligence that makes enforcement decisions meaningful.”[12]
Similar Challenges, Similar Patterns for Process, Coding, and Knowledge Agents
The same question shows up in each environment: what is the agent allowed to do for this task, and which service checks before the action happens?
Process Agents in Agentic Process Automation
In Agentic Process Automation, process agents run inside known workflows. The enterprise knows the task definition, allowed tools, expected evidence, and release path before execution starts. The grant can be narrow because the workflow is known.
An invoice-review agent may receive authority to read the invoice, retrieve a purchase order, compare vendor records, create an exception, and draft a recommendation. It should not receive payment-release authority, bank-detail update authority, or external email authority unless the task reaches a step that explicitly grants it. Task-scoped execution grants sharply reduce blast radius in this pattern.
The Tool Executor checks that narrow grant before the agent can call a payment tool, vendor lookup, case system, document service, or workflow action.
Coding Agents
Coding agents need a different balance. They work close to a developer, and they need enough flow to inspect files, edit code, run tests, and open pull requests without constant interruption. The unsafe default is broad inherited workspace authority: raw shell, package managers, browser access, cloud CLIs, secrets, deployment scripts, and production credentials.
The practical pattern is to replace dangerous ambient tools with narrower controlled tools. A coding agent can receive approved tools for reading files, applying patches, running tests, retrieving logs, or opening a pull request. Raw Bash, cloud mutation, secret access, production database operations, and deployment commands should require explicit grants tied to the task.
The goal is developer flexibility with a record. The developer can request temporary authority when the task requires it. The executor checks that authority, limits its scope, and records the action.
Knowledge-Worker Agents
Knowledge-worker agents usually do not need shell access. Their risk comes from data reach and data movement. They may read customer records, contracts, messages, spreadsheets, HR material, project documents, and internal knowledge bases. They may also write emails, update CRM fields, create tickets, or send documents.
Each permission can look reasonable on its own. The combined workflow can still violate policy. A renewal-preparation agent may read Salesforce and draft an email. That does not mean it may place discount strategy, risk notes, support history, or regulated customer information into an outbound message.
For these agents, start with read-only access for approved sources and require separate grants for data movement or external communication. The executor checks the data domain, destination, recipient, release path, and task purpose before anything leaves the controlled workspace.
Check Simple Requests Locally; Escalate Risky Requests
Some requests are simple enough to check locally against the signed grant and registry metadata. That keeps Trust Authority out of the path for every low-risk request. Approved skill retrieval, read-only lookup, bounded transformation, evidence writing, and low-risk internal data access usually fit this pattern. The service verifies the signature, audience, expiry, task, capability, action, schema, and registry state. If the request matches the grant, the service proceeds.
Live Trust Authority is required when the grant may no longer match current reality. A task may have been cancelled, a tool disabled, a tenant suspended, an approval withdrawn, a policy changed, or a threshold crossed. High-risk actions should also come back for a live decision: payment execution, customer communication, destructive updates, entitlement changes, external API calls, regulated outputs, and unusual paths should trigger checks, holds, or human approval.
The boundary works only if both paths have clear outcomes: local checks for routine work, live decisions for changing risk, and denial when neither path can approve the request.
Fail Closed When the Grant Is Missing, Expired, or Revoked
The rule is simple: fail closed. Missing grant, invalid signature, expired grant, wrong audience, unavailable registry, disabled tool, malformed payload, failed schema validation, denied introspection, or unsupported path should stop execution. Any cache fallback must be explicit, bounded by risk tier, and recorded as evidence. Permissive fallback recreates broad workspace access under enterprise vocabulary.
Revocation is the hard case because authority can change while work is already moving. If a grant is revoked mid-task, services need clear behavior based on risk and side effect. A not-yet-started call should be denied. A queued call should be cancelled or held. A long-running read may be allowed to complete and flagged, depending on policy. A destructive or externally visible action should require live confirmation before commit where practical.
The platform must define what happens when authority changes during execution. Without that, revocation exists on paper while agents keep operating under stale authority.
Record Every Decision Before the Output Leaves
The platform should produce evidence throughout execution. Skill Services, the Tool Executor, route gateways, Trust Authority, and other control points emit events whenever they allow, deny, hold, revoke, or execute. The core evidence chain matters: grant presented, capability resolved, skill delivered, tool requested, request denied or allowed, tool executed, output produced, release checked.
That evidence feeds compliance audit, SIEM integration, Trust Authority policy feedback, incident investigation, and operational improvement. It lets the enterprise prove what happened and which controls were tested, instead of reconstructing the agent’s behavior from a transcript after the fact. Yadav describes the production pattern as “constraining the environment, enforcing policy at runtime, observing behavior continuously, and preparing a recovery path.”[13]
Before anything leaves, check the grant one more time. A valid internal path does not automatically mean the result can leave the process. Release controls inspect the task grant, required evidence, denied requests, unresolved exceptions, data classification, output destination, and applicable policy. A correct-looking output should be held if the agent produced a customer response without the required evidence event or after a denied tool request.
The Control Point Is the Tool Boundary
The orchestrator sends the task with a signed grant, but it should not become the only checkpoint. The Agent Runtime carries the grant and requests skills and tools. Skill Services and the Tool Executor check the grant against the registry before serving material or executing work. High-risk requests return to Trust Authority. Evidence events are emitted throughout. The release boundary checks the completed path before output leaves the process.
Enforcement is the third of three architectural layers in the series. Identity makes the actor known. Authorization defines the task boundary. Enforcement turns that boundary into service decisions.
The agent asks. Enterprise-controlled services check, run, deny, hold, release, and 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]: Tom Carter, “A startup founder says an AI coding agent deleted his company’s production database,” Business Insider, April 28, 2026, https://www.businessinsider.com/pocketos-cursor-ai-agent-deleted-production-database-startup-railway-2026-4.
[2]: Hasan Chowdhury, “Replit’s CEO apologizes after its AI agent wiped a company’s code base in a test run and lied about it,” Business Insider, July 22, 2025, https://www.businessinsider.com/replit-ceo-apologizes-ai-coding-tool-delete-company-database-2025-7.
[3]: Eric Broda, “Agents Are Here. They Are Multiplying. The Enterprise Security Model Is Not Ready.”, The Agentic Mesh Substack, https://agenticmesh.substack.com/p/agents-are-here-they-are-multiplying.
[4]: Eric Broda, “Agent Identity - The Foundation for Secure Agents,” The Agentic Mesh Substack, https://agenticmesh.substack.com/p/agent-identity-the-foundation-for.
[5]: Eric Broda, “Secure Agent Authorization: Tasks as the Authorization Boundary for Enterprise Agents,” The Agentic Mesh Substack, https://agenticmesh.substack.com/p/secure-agent-authorization-tasks.
[6]: Eric Broda, “Agentic Process Automation,” The Agentic Mesh Substack, https://agenticmesh.substack.com/p/agentic-process-automation.
[7]: Rafe Rosner-Uddin, “Amazon service was taken down by AI coding bot,” Financial Times, February 20, 2026, https://www.ft.com/content/00c282de-ed14-4acd-a948-bc8d6bdb339d.
[8]: 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/.
[9]: Johann Rehberger, “Agent Commander: Promptware-Powered Command and Control,” Embrace The Red, March 16, 2026, https://embracethered.com/blog/posts/2026/agent-commander-your-agent-works-for-me-now/.
[10]: Cloud Security Alliance, “New Cloud Security Alliance Survey Reveals 82% of Enterprises Have Unknown AI Agents in Their Environments,” April 21, 2026, https://cloudsecurityalliance.org/press-releases/2026/04/21/new-cloud-security-alliance-survey-reveals-82-of-enterprises-have-unknown-ai-agents-in-their-environments.
[11]: Graham Rowe, “Nobody’s Watching Your AI Agents,” Phase Transitions AI, April 1, 2026,
.
[12]: SACR and Kevin He, “Runtime Security for AI Agents: An Identity Governance Perspective,” Software Analyst Cyber Research, March 18, 2026,
.
[13]: Ankur Yadav, “Runtime Verification for AI Agents in 2026: Policies, Sandboxes, and Safe Execution,” The Backend Developer, May 5, 2026,
.