Agent authority and the lethal trifecta

Once an agent can act, the useful question is not "did it intend well?" but "could it have done more than its task requires?". The engine encodes this as invariants over the agent’s effective authority — the set of actions reachable through its tools — and checks that this authority does not exceed the agent’s declared purpose.

• ▸Delegated authority must only decrease: a sub-agent can never hold more than its parent.
• ▸Reachable tool authority must not exceed purpose: the tools in reach must match the job.
• ▸Irreversible actions require a human in the loop, and the approval must bind to the exact effect.

A specific, dangerous pattern recurs: when a single agent has access to private data, exposure to untrusted content, and the ability to exfiltrate, those three capabilities together are enough for an injected instruction to read a secret and send it out. The engine reasons about whether these three are co-reachable, because any system where they are is one successful injection away from data loss.

Private data

Secrets, internal records, anything the agent can read but should not leak.

Untrusted content

Anything an attacker can influence — a document, a web page, a tool result.

Exfiltration

Any capability that moves data outward — a request, an email, a write to a shared store.

Other invariants cover the quieter failure modes: untrusted memory must not cause a privileged action (a note planted once must not steer unrelated future sessions); a poisoned output must not propagate across agents; request amplification must stay within budget, so an agent cannot be turned into a denial-of-wallet. Human-in-the-loop approvals are themselves guarded: an approval must bind to the exact effect it authorizes, and approvals must not be fatigued into rubber-stamping.

Tools can lie about themselves. Under the Model Context Protocol, a tool description or result is itself untrusted input. The engine checks that tool metadata carries no hidden instructions (tool poisoning), that a tool has not drifted from its approved schema (rug-pull), that two tools sharing a name do not diverge in authority (shadowing), and that the overall topology preserves trust boundaries. A change to a tool’s schema invalidates any prior approval of it.