The prompt is not permission
There is a dangerous assumption built into many AI systems: that if a model decides it wants to do something, it should be able to. In a domain where actions move real money, that is exactly backwards. An agent should not gain power because a prompt — from a user or from the model's own reasoning — asks for it. The right model is the inverse: an agent requests a capability, and a separate runtime decides whether that capability is registered, allowed, healthy, appropriate, and safe enough for the task at hand. The request is not the grant.
What a capability is
A capability is any power an agent might use, and treating them all uniformly is what makes them governable. A capability can be:
- a skill that shapes a specialist's workflow,
- a deterministic function,
- a tool that performs an action,
- a read-only resource that exposes data.
By naming each of these as an explicit capability rather than ambient access, the system gains a single chokepoint where every power an agent reaches for can be checked — instead of trusting the agent to police itself.
The five questions before any capability runs
The discipline is that a requested capability passes a series of checks before it is granted. Each question closes off a class of failure:
- Registered — is this a known, declared capability, not something the agent invented or hallucinated? Unknown capabilities are refused outright.
- Allowed — does the current user, tenant, and context have permission to use it? Permission is contextual, not global.
- Healthy — is the underlying tool or service actually working right now? A degraded dependency should not be invoked blindly.
- Appropriate — does it fit the task? A capability can be registered and allowed yet still be the wrong tool for what is being done.
- Safe enough — given the risk of the action, are the right gates (approval, prechecks) in place before it proceeds?
Only a capability that clears all five is granted. This is capability-based security applied to AI agents.
Why sandboxing matters around money
The reason this rigor is non-negotiable in wealth management is the blast radius. A general chatbot with a buggy or manipulated tool call produces a wrong answer. An autonomous financial agent with unchecked capabilities could move funds, place trades, or expose sensitive data. Sandboxing — confining an agent to exactly the capabilities it has been granted, and no more — is what contains that blast radius. The agent operates inside a bounded space where the worst it can do is limited by design, not by hope.
Least privilege, by default
The principle underneath all of this is least privilege: an agent gets the minimum power needed for the task, granted at the moment it is needed, and no standing access beyond that. This is the same principle that governs well-designed human access control, applied to autonomous software. It directly counters the failure mode of an over-permissioned agent that, through a bad instruction or a manipulated input, reaches for a power it should never have had in that moment.