Hard Boundaries for AI Agents: What a CTO Should Require

TL;DR

• In 200 days into the frontier (2 November 2026), JPMorganChase’s Global Technology Leadership Team writes: “Capability, however, should not automatically determine authority.”
• Their rule of thumb: “Before expanding what agents can do, establish what they cannot do.” Access follows the task, and oversight is proportional to consequence.
• Below are eight requirements I would put in front of any agent rollout, and how I apply them to the agents that run my own work and side projects.

What the JPMorganChase post actually says

The article is mostly about cyber resilience in a period where vulnerability discovery is accelerating. One section, “Put hard boundaries around AI agents”, is the clearest short statement on agent governance I have read from a large enterprise this year. The core lines:

“Frontier technologies are moving from answering questions to taking action. Agents can increasingly interact with enterprise systems, access information and execute tasks with limited human involvement. Capability, however, should not automatically determine authority.”

“Access should be based on the task, not on the theoretical reach of the model. Human oversight should be proportional to consequence: a reversible, low-impact action warrants a different control than moving money, changing production systems or communicating with a customer.”

They then list four controls: give agents only the access required for the task, make agents identifiable and monitor them in real time with traceability, maintain the ability to restrict or stop an agent quickly, and reassess boundaries as capabilities and dependencies change.

That is a good list. It is also abstract enough that most teams will nod and then ship an agent with a personal access token that can do everything its owner can. So here is how I translate it into requirements.

Eight requirements a CTO should put in writing

1. A deny list before an allow list

Write down what the agent must never do, in plain language, before discussing what it should do. In my own setup the deny list is short and absolute: no sending email or messages, no publishing, no merging to main, no purchases and no deleting anything outside a sandbox without a human approving that specific action. Everything else is negotiable.

2. Task scoped credentials

Each agent gets credentials for its task, not its owner’s. Read only by default. Write access is added per system, per scope, when a concrete task needs it. A useful test: if the agent’s token leaked today, what is the worst thing someone could do with it?

A real example from this week: an agent preparing an access configuration change stopped before touching anything because the API token it had was read only. It reported what permissions it would need and asked. That is the boundary working, not failing.

3. A distinct identity per agent

Agents should act under their own identity so logs, commits and API calls can be attributed. Shared service accounts make investigation slow. Separate bot identities in source control, separate API keys per agent role and a name in every message the agent produces are cheap and make “who did this?” a lookup rather than a debate.

4. Action logs that support investigation

The JPMorganChase text asks for traceability “for investigation and recovery”. In practice that means you can answer, for any action: which agent, which task, which input, which tool call, which result, and who approved it if approval was required. Store it somewhere the agent cannot edit.

5. Approval tiers by consequence

Not everything needs a human. Make three tiers explicit:

The trap is letting tier three actions hide inside tier one workflows. A “summarise and reply” agent is a tier three agent.

6. A tested stop switch

“Maintain the ability to restrict or stop an agent quickly” is only true if you have tried it. Know which switch stops each agent: revoke the token, disable the schedule, remove the tool. Practise it once per quarter, and write down how long it took.

7. Cost is a permission too

Model choice, run frequency and paid tools are actions with consequences. I run cloud agents on an automatic model policy by default and treat any upgrade to a premium model or any new paid service as an approval item, the same as a purchase. When an agent drifts from that default, the fix is a written rule it reads on every run, not a one off correction. More on this in guardrails in practice.

8. A boundary review on a calendar

Boundaries drift. New tools get connected, models get better, and an agent that was safe with read access gets write access “just for this one task”. Put a review date on each agent: what it can reach today, what it actually used, and what can be removed.

What to ask in the next steering meeting

If you are the person who has to sign off on agents, these questions get to the truth quickly:

• Show me the list of things this agent cannot do. Where is it enforced, in code or in a prompt?
• Whose credentials does it use? What is the worst case if they leak?
• Can you show me the log entry for the last action it took and who approved it?
• How do we stop it in the next five minutes, and when did we last test that?
• What does it cost per accepted outcome, and who approves a model upgrade?

The JPMorganChase post ends with a principle that applies directly here: every action should end in an evidence request, asking management to “show it, not assure it.” Agent governance is the same. A slide that says “human in the loop” is assurance. A log line with an approver’s name is evidence.

A starting checklist

• Written deny list per agent
• Read only credentials by default, write scopes added per task
• Separate identity per agent in source control and APIs
• Immutable action log with approver field
• Approval tiers defined, tier three actions always gated
• Stop switch documented and tested this quarter
• Default model policy and approval for paid upgrades
• Boundary review date on every agent

FAQ

What does “hard boundaries for AI agents” mean? Enforced limits on systems, data and actions, set before capabilities are expanded.

Should every action need approval? No. Oversight should match consequence. Irreversible and external actions need explicit approval; reversible internal work can run unattended with logs.

What is the minimum before go live? Deny list, scoped credentials, agent identity, action log, approval tiers, tested stop switch and a review date.

Where do spend limits fit? Cost is a permission. Bound model choice, frequency and paid tools like any other action.

Source: JPMorganChase Global Technology Leadership Team, “200 days into the frontier: What we know and what to do now”, 2 November 2026.