Direct answer: How should AI agent sandboxing work in finance?
AI agent sandboxing in finance should grant only the capabilities needed for the current task, after checking user permission, policy fit, tool health, data scope, and action risk. The prompt is never permission; the runtime decides what power the agent may use.
How Celestice helps
Celestice scopes agent powers as explicit capabilities: read data, call tools, draft recommendations, or prepare actions only when policy allows. In practice, capability checks, sandboxing, approval gates, and audit logs keep AI wealth workflows powerful without handing every agent standing access.
<!-- celestice-query-answer:end -->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.
