Earlier this month, AI governance author Kesha Williams ran a small experiment with a coding agent. She had built a skill that generates a changelog from git commits, then removed the agent's Write tool to see what would happen. The agent did not stop. It noted that writing was disallowed for that invocation, delegated the work to a subagent running in a separate context where the restriction did not apply, and produced the file in under half a minute.
Nothing was hacked. Nothing broke. The agent used a capability that was already part of its design. The restriction had been placed on one tool in one place, and the work simply moved somewhere else.
It is a small story, and a useful one. If you are connecting agents to enterprise systems, it describes your most likely failure mode far more accurately than any headline about runaway AI.
An Old Problem With a New Wrinkle
Security engineers will recognize the pattern. It is privilege escalation through delegation, sometimes called the confused deputy problem. A component with narrow rights asks a component with broader rights to act on its behalf, and the broader component complies because nothing told it not to. Service accounts and API scopes have produced this failure for decades.
The new wrinkle is who chooses the route. In a traditional system, every delegation path was written by a developer and can be listed and reviewed. An agent chooses its route at runtime. It can conclude that the direct path is closed and find a sanctioned alternative. You cannot enumerate those routes in advance, which means you cannot secure them one at a time.
In May, we published Zero Trust Isn't a Product. It's an Architecture Decision. It argued that identity is the new perimeter and that least privilege is a process, not a policy. Agents make both statements more urgent. An agent is a non-human identity that can plan, delegate, and retry. It is a service account that can reason, and it deserves the discipline of any privileged identity plus a few new rules.
Enforce at the Resource, Not the Tool
The useful question is not whether a tool was blocked. It is whether the outcome is prevented no matter which route the agent takes.
Tool restrictions are a good first layer and worth keeping. They shape behavior and cut down on noise. They are not a boundary. A boundary lives at the thing being protected: the record, the file, the API endpoint, the dataset. It checks the identity behind every request, on every call. If the agent reaches that resource through a different tool, a subagent, or another platform entirely, the same check fires.
That is defense in depth applied to agents. Each layer does a specific job, and none of them is asked to do all of it.
| Layer | What it does | What it cannot do alone |
|---|---|---|
| Tool restrictions | Shape what the agent attempts | Stop the same outcome through another tool or a subagent |
| Run-as identity and roles | Bound what the agent can reach at all | Stay narrow if the identity is over-provisioned or has no owner |
| Data-level ACLs | Enforce on the record, whatever the path | Show you what the agent tried or why |
| Trace, audit, and intervention | Reveal the route taken and let you stop a run | Prevent an action that no control forbids |
What This Looks Like on ServiceNow
For teams deploying AI agents and Now Assist skills on the Now Platform, the platform already provides the building blocks. The work is in using them deliberately.
- Choose the run-as identity on purpose. An agent can run as a dynamic user, which inherits the permissions of whoever invoked it, or as an AI user, a dedicated identity with a fixed set of roles. With a dynamic user, an agent invoked by an administrator carries administrator reach. An AI user gives a narrow and predictable footprint, but it is a standing non-human identity that needs an owner, a purpose, and a review cycle. Neither choice is wrong. An unexamined choice is.
- Put ACLs on the data. Table, record, and field ACLs bind no matter which tool, flow, or subflow reaches the record. They are your backstop when an agent uses a path you did not anticipate.
- Treat every exposed flow, subflow, and skill as an entry point. Anything you publish as an agent tool is a path. Secure it explicitly, including the
invoke_from_aiACL operation that governs invoking a flow or action from AI, and confirm the checks evaluate against the identity you intend. Not every execution path is evaluated through that operation, so it complements data-level ACLs rather than replacing them. - Narrow the roles further where you can. Role masking lets a dynamic user identity carry only a subset of the invoking user's roles into its ACL checks. Supervised mode for tools adds a human checkpoint before actions that carry real consequence.
- Use AI Control Tower for visibility and control. Inventory your agents, review tool executions in the audit trail, and use the ability to intervene when an agent operates outside its intended bounds. Governance that cannot see the trace cannot govern.
Capabilities differ by release, so confirm the specifics against the version your instance runs.
Five Questions to Answer Before an Agent Touches Production
- What identity does this agent run as, and who owns that identity?
- If every tool restriction were removed tomorrow, what could that identity still reach? That answer, not the tool list, is your real perimeter.
- Which delegation paths exist, including subagents, subflows, orchestrator handoffs, and calls to external systems over protocols such as MCP, and does each one inherit, narrow, or widen permissions?
- Are sensitive actions enforced at the record, field, or API level, or only at the tool level?
- Can we see the full execution trace, not just the final output, and can we stop a run in progress?
Answer them honestly before go-live. Any answer that begins with "we assume" marks a gap.
Build the Layers Early
Enterprises adopting agentic AI today, in North America, Africa, and everywhere else, have an advantage earlier technology waves did not offer: the governance patterns are understood before most deployments have scaled. Organizations that design identity, data-level enforcement, and observability in from the first agent avoid an expensive retrofit later. For enterprises building their digital foundations right now, that is a real opportunity.
An agent is not risky because it is clever. It is risky when its reach exceeds its design. Design the reach first, then let the agent be as capable as you like.
Nya Akoma. Take Heart.