Clear authority.
Agents act only through declared tools, permissions and analytical components. Human-only actions require explicit approval, and generated application code runs with no more authority than its instance.
Exiled.AI / Security & Compliance
Clear authority. Isolated state. A dependency-free core.
Exiled Markets runs in the browser. Each user works in a separate application instance, and the agent operates through declared tools and permissions. A security review should examine those boundaries—and the deployment choices around them.
Request a security walkthrough →01 / ACCESSBrowserNothing to install
02 / ISOLATIONUser instanceSeparate server and state
03 / AUTHORITYAgent harnessDeclared tools and limits
04 / EVIDENCEReviewable workSources, methods, assumptions
What is built in
Three design choices come first.
These design choices shape the review. They are not a substitute for checking identity, vendor access, operations, and contractual controls in a real deployment.
Isolated state.
Each user has a self-contained application stack with its own server, cache and state. There is no shared application state between users. It is containerized; the hosting provider supplies the microVM layer.
A dependency-free core.
The Exiled Python runtime uses the standard library, without third-party math, dataframe, model-wrapper, server or UI frameworks—a far smaller tree for a supply-chain review. External services and hosting still need review.
Control status
What is built in, and what is reviewed.
“Built in” means part of the Exiled instance. “Per deployment” means the control depends on the environment and is agreed and tested with your team.
| CONTROL | STATUS | NOTES |
|---|---|---|
| Per-user instance and state | Built in | Separate server, cache and state per authenticated user. |
| Instance isolation layer | Per deployment | Container built in; microVM supplied and operated by the hosting provider. |
| Authentication | Per deployment | At the gateway, before the user instance; identity provider and session policy agreed per deployment. |
| State-changing requests | Built in | Same-origin token required; it is not an identity credential. |
| Agent tool authority | Built in | Declared tools, permissions and limits; human-only actions need explicit approval. |
| Outbound network from generated code | Per deployment | Governed by an egress policy set for the environment. |
| External model use | Per deployment | Routing, permitted data, vendor terms and retention agreed and documented before use. |
| Untrusted inputs | Built in | Provider responses and uploaded files cross a typed validation boundary; prompt injection is tested, not declared solved. |
| Provenance on results | Built in | Sources, methods, assumptions and timestamps travel with figures. |
| Third-party Python packages in the core | Built in | None required; the standard library only. |
| Delivery | Built in | Browser only, across desktop, tablet and phone; nothing to install. |
Security review / Common questions
What a CISO will ask.
Direct answers where the architecture is defined. Deployment-specific controls should be documented and tested with your team.
Request a security walkthrough →01Who can reach a user’s application?
Authentication happens at the gateway before the user instance. The runtime also uses a same-origin token for state-changing requests; that token is not an identity credential. We review identity integration, session policy, and origin access for the deployment.
02Is one customer’s data shared with another?
Each user’s application server and state are separate. The stack runs in a container on the hosting provider’s microVM infrastructure. The provider’s isolation controls and any shared upstream services are part of the deployment review.
03What leaves the user instance for an AI model?
If an external model is enabled, the context sent to it may leave the instance. Model routing, permitted data, vendor terms, and retention need to be agreed and documented before use. The harness controls which tools the agent can call; it does not make a third-party model private by itself.
04Can an agent execute code or reach the network?
Generated application code runs with the instance’s authority. The harness exposes declared tools and limits; outbound capabilities require an egress policy, and human-only actions require explicit approval. Production review should inspect code, credentials, permitted destinations, and least-privilege access.
05How are untrusted prompts, files, and feeds handled?
Provider responses and uploaded files cross a validation boundary. Imports can be bounded and typed; tool permissions limit what a misleading prompt or document can induce an agent to do. Prompt injection remains a risk to test, not a problem any harness can declare solved.
06What does “zero dependencies” actually cover?
It describes the core Python runtime: no third-party packages for its math, dataframe, model wrapper, server, or UI framework. It does not exclude dependencies in browsers, data connectors, model services, or hosting. Those have their own inventory and review.
07How are transport, secrets, and stored data protected?
Model requests use HTTPS. Identity, secret storage, encryption at rest, and network restrictions involve the gateway and hosting environment. We document the chosen configuration and responsibilities for a deployment rather than promising a universal setup.
08What about logging, retention, and incidents?
These operational commitments belong in the deployment and service terms. A review should identify what is logged, who can access it, how long it is kept, when it is deleted, and how incidents are reported and handled.
09What evidence is available for diligence?
We can review architecture, data flows, tool permissions, deployment boundaries, and vendor access with your team. Confirm any independent testing, audit reports, certifications, data locations, and subprocessor commitments for the specific service before relying on them.
The review boundary
Know who owns each control.
EXILED APPLICATIONCode and agent authority.
Separate application state, tool policy, input validation, and defined analytical methods are part of the Exiled instance.
DEPLOYMENT & PROVIDERSIdentity and operations.
Gateway access, hosting isolation, model and data providers, network rules, logging, and retention are reviewed in the chosen environment.
We can walk through data flows, permissions, and responsibility boundaries with your security team. This page describes architecture, not a certification or a promise about controls that depend on your deployment.
For security teams
Request a security walkthrough.
We will work through identity, data handling, model routing, supply chain, and operational requirements with the right technical people in the room.