Capability Is Not Authority: Turning JPMorganChase's Agent Guidance Into Enforceable Controls

2026-11-03 · Aldo Pietropaolo

On November 2, 2026, the JPMorganChase Global Technology Leadership Team published 200 days into the frontier: What we know and what to do now. It is a guide for CEOs on enterprise resilience as frontier AI accelerates attackers, and most of it covers unsupported technology, internet-facing systems, suppliers, and physical dependencies.

One section addresses AI agents. Its central line is worth putting in front of every team deploying them: <span class="text-primary-400">"Capability, however, should not automatically determine authority."</span>

This article focuses solely on that agent security guidance. It is Watchlight AI's independent interpretation of how to implement it, written for the security and identity teams who will be asked to do so. It does not suggest any relationship with JPMorganChase or any endorsement by them.

Why do agents need their own boundaries?

The guide observes that agents are shifting from answering questions to taking action, interacting with enterprise systems and executing tasks with limited human involvement. Its framework lists autonomy as one of the shifts AI brings: agents gain access and authority without the same certainty that they will act as intended.

Two properties make that a security problem. An agent can exercise the same permission repeatedly at machine speed, so a mistake repeats before anyone sees it. And an agent can delegate, handing work to other agents and tools, so one grant of authority can spread across a chain of actors. Both raise the cost of authority that is broader than the task. That is the gap Watchlight was founded to close: governing what agents do with the access they hold.

What should an agent never be allowed to do?

The guide's first instruction concerns order: establish what agents cannot do before expanding what they can. In practice, that requires three decisions.

Separate capability from permission. Connecting a tool to an agent grants capability. Permission to use that tool, including which resources and for which task, is a separate decision. Deny by default means an action is refused unless policy permits it for this agent and this task, regardless of which tools are connected.

Write a prohibited-action list for each agent's purpose. A collections agent may need to send external email and should never change payment details. A reconciliation agent may need to update records and should never contact customers. Deletion, payment changes, access grants, and external communication are common entries, but the list is tailored to each agent's role; there is no universal one.

Keep policy out of the agent's reach. An agent must not be able to change the policies that govern its authority. Policy administration belongs to people, who manage it under their own credentials and review.

The guide also asks that access follow the task rather than the model's theoretical scope. For delegation, the rule is simple: authority delegated to a sub-agent may never exceed what its parent holds.

How much human oversight does an agent action need?

The guide calls for oversight proportional to consequences and contrasts a reversible, low-impact action with moving money, changing production systems, or communicating with a customer. That principle becomes a policy table. This one is illustrative:

Reading is not automatically safe. A few approved records for the task at hand are different from a bulk export or from reading data the agent then sends outside the company.

For consequential actions, an approval must be tied to the action itself: the recipient and content of a message, the amount and payee of a payment, the target resource of a change, and an expiration. If any of those change materially after approval, the action needs a new decision. An approval for one email should not cover a different one.

A table like this will not, by itself, keep approval requests rare. It makes the trade-offs explicit, so you can tune limits until approvals land where a person's judgment adds value.

The four controls, made concrete

The guide outlines four actions for agents. Here is what each requires in practice.

1. Task-scoped access, enforced. The guide asks that agents receive only the access their task requires, with limits on the systems, data, and actions available to them. The key word is enforced. Instructions in a prompt are advice. Enforcement means each governed action is evaluated against policy before execution, by a control outside the model's control, at the boundary where the action occurs. The model can propose any action it likes. It cannot override the decision.

Enforcement also has to close alternate paths. A denied action must not remain reachable through a different tool, a different credential the agent holds, or a direct network route that bypasses the control. In practice, that means agents hold no standing credentials for systems they reach through governed paths, and network egress is limited to traffic that passes through enforcement.

2. Attributable identity and traceability. The guide requires that agents be identifiable, monitored in real time, and traceable for investigation and recovery. This means each agent has a unique identity and an accountable owner, rather than a shared service account, and each action is linked to its run and to the delegation chain that produced it. When a person starts work, their authority context should accompany it. For scheduled or autonomous work, the record should identify the accountable service or owner.

Useful evidence captures more than a timestamp. For each consequential decision, record the policy version, the relevant inputs and context, the decision, the enforcement result, and the action's outcome, as observed by the system. A signed decision record proves what was decided. It does not, by itself, prove that a downstream system completed the action or that every action passed through the control.

3. The ability to quickly restrict or stop an agent. The guide's advice on incident response applies directly: decision rights and emergency authority should be defined before an event so teams are not inventing a process during one. For agents, that means responses are defined in advance, each with a different scope:

• Stop the run: this execution ends; the agent can run again.
• Quarantine the agent: it cannot act until an authorized person releases it.
• Cut off the delegation subtree: the sub-agents a run started stop with it.
• Revoke authority: the agent loses its trust until someone restores it.

Each prevents future actions. None reverses an already completed action, so recovery for completed work still runs through the affected systems. Decide in advance who may initiate each response and who may authorize a release, and document it.

4. Reassess boundaries as things change. The guide recommends revisiting boundaries as capabilities, use cases, and dependencies evolve. Distinguish two kinds of change. Connecting a new tool or MCP server changes what an agent can reach, so its permissions need review. Swapping in a new model changes how the agent behaves without granting new permissions, so behavior needs monitoring even when access is unchanged.

When you change policy, evaluate the proposed rule in observe mode first, alongside the policies already enforced, and review what it would have refused. Existing protections remain enforced throughout. Mandatory safety restrictions should never run in observe mode only.

Show it, rather than assure it

The guide closes by asking management for evidence rather than assurance. For agents, a useful set of evidence includes:

• Actions refused in production, with the policy and limit each one crossed.
• Approvals granted, with what each approval covered and when it expired.
• A list of agents with their owners, prohibited-action lists, and the date their boundaries were last reviewed.
• One real action traced from the agent back through its run and delegation chain to the person or service accountable for it.
• A timed containment drill.

Run the drill against a realistic scenario: one with queued work, requests in flight, sub-agents holding delegated authority, and credentials that may still be valid. Measure the time until prohibited downstream actions are blocked, which matters more than the time until the parent process stops. Record who initiated the containment, who approved the release, and anything that continued running.

The guide asks that exercises test decisions as well as technical fixes. An agent drill tests both: whether the control works and whether the people with authority to use it know they have it.

Where Watchlight fits

Watchlight AI Beacon is the control plane for Agent Runtime Governance. It is how we implement these controls; the requirements above apply regardless of what you use.

• Enforcement before execution. Governed actions are evaluated by a deterministic policy, denied by default, and enforced both in the agent framework and at a proxy on the wire. A request without a valid run credential is refused and logged. Upstream keys can remain in a secrets broker that injects them at the proxy, so agents never hold them. Closing direct network routes still depends on your own egress controls.
• Delegation. A sub-agent's authority must fit within its parent's: it can match it but never exceed it. A request for more is refused, with a record of what was asked and what the parent held.
• Approval is bound to the request. An action awaiting approval waits for an operator in the same tenant, and the requester cannot approve it. The approval is bound to the request as Beacon evaluated it, including its context, run, and governing policies, so a changed request or an edited policy triggers re-evaluation. An approval is single-use and short-lived.
• Policy is out of the agent's reach. Changing policy requires an administrator; agent credentials cannot edit it.
• Containment. A policy or an operator can stop a run, quarantine an agent until an operator lifts the quarantine, cut off a delegation subtree, or revoke an agent's trust. These actions block further actions. They do not reverse actions already completed.
• Observe mode. A policy can run in observe mode, recording what it would have denied while all other policies remain enforced.
• Evidence. Each decision records the policies evaluated, the determining policy and reason, the delegation chain, and where it was enforced. Decisions are written to a signed, hash-chained audit log. When a run starts with a verified identity provider token, the person it acts for is also recorded.

Five questions for your next agent review

1. For each agent in production, what is it prohibited from doing, and where is that prohibition enforced?
2. Does any agent hold permissions broader than the task at hand, or credentials that bypass enforcement?
3. Which agent actions require a person, and does each approval apply to the exact action it covers?
4. How long does it take to block a contained agent's prohibited downstream actions, including those of its sub-agents?
5. What evidence could you present to your CEO this week without preparing it first?

The fifth question is a quick way to identify gaps. Having the evidence does not prove the controls work everywhere. Not having it tells you where to look first.