Per-deployment boundary
Agents are deployed with dedicated Worker configuration and a named container sandbox rather than one shared long-running app process.
01
security model
secure deployed agents
Security boundaries for production AI agents.
Vertical agents carry credentials, workflow memory, tool access, and untrusted inputs. We secure them with isolated infrastructure, encrypted secrets, scoped application controls, and prompt-injection defenses shaped around the workflow.
- runtime
- isolated Worker and sandbox per deployment
- secrets
- AES-256-GCM encrypted before storage
- access
- Cloudflare Access plus scoped gateway tokens
- agent risk
- least privilege, approvals, and injection probes
02
posture
control summary
Security is written into the deployment model, not added after launch.
Buyers do not need another vague promise that an AI system is secure. They need to see where authority lives, how credentials are handled, and what happens when untrusted content reaches the agent. The controls below are the foundation we can substantiate from the deployed agent platform.
Authenticated encryption
API keys, bot tokens, and integration credentials are encrypted with AES-256-GCM before storage.
Scoped admin and service paths
Hosted/admin surfaces use Cloudflare Access policies; server control paths use deployment-scoped gateway tokens.
Separated state
Deployment state is organized behind per-worker database, storage, config, and backup boundaries.
Recon monitoring
Suspicious path probes, bursty scans, and repeated range activity are monitored across managed worker hosts.
Prompt-injection review
Sensitive flows can be probed for injection, exfiltration, authorization bypass, memory leakage, and tool escalation.
03
control layers
infrastructure, application, ai
A secure agent is an operating boundary, not a chatbot with a policy page.
01Infrastructure security
Reduce blast radius at the deployment boundary.
A production agent should not feel like another tab in a shared app server. The runtime, sandbox, configuration, and storage paths are treated as deployment boundaries, so one workflow can be reviewed, changed, or constrained without widening the whole platform.
Dedicated Worker configuration, named container sandboxes, per-worker storage prefixes, Cloudflare Access for protected surfaces, and suspicious recon monitoring.02Application security
Constrain the paths where agents receive authority.
Most practical agent risk shows up in ordinary product paths: a callback URL, a channel token, a rushed redeploy, a chat burst, or an admin action. Those paths need validation and narrow credentials before the model ever gets involved.
AES-256-GCM secret encryption, strict request schemas, HTTPS-only callback validation, private-network callback blocking, rate limits, allowlists, and scoped gateway tokens.03Prompt-injection security
Assume untrusted text will try to become instructions.
Prompt injection is not fixed by writing a stronger system prompt. The safer pattern is to make the agent boringly constrained: fewer tools, clearer allowed actions, sandboxed execution, and human review before decisions with money, access, publishing, or customer impact.
Separate untrusted content from privileged instructions, limit tools to the deployed workflow, probe exfiltration and escalation paths, and keep high-impact actions behind review.why this matters
The model can read a document, but the system decides whether that document is context, a command, or just hostile text. The model can suggest an action, but the deployment boundary decides which tools exist, which credentials are available, and when a human has to approve the next step.
Infrastructure controls
- Dedicated Worker configuration per production deployment
- Named container sandbox per agent instance
- Per-worker storage and backup prefixes
- Cloudflare Access policies for protected hosted surfaces
- Suspicious recon and burst scanning alerts
Application controls
- AES-256-GCM encryption for stored secrets
- Strict request schemas for assistant lifecycle APIs
- HTTPS-only callback URLs with private-network host blocking
- Per-user rate limits for chat traffic
- Channel allowlists and scoped gateway-token control paths
Agent controls
- Separate untrusted user or document content from system intent
- Limit tools and records to the workflow being deployed
- Require review before spend, access, publishing, or customer impact
- Probe injection, exfiltration, memory leakage, and authorization bypass
- Keep risky operations behind explicit workflow controls
04
security narrative
the important part
The agent should never be the only thing standing between a user and a business action.
In normal software, permissions are enforced by the application. In agent software, people are tempted to let the model reason about permissions in natural language. That is not enough. We design the surrounding system so the agent has a smaller set of tools, a narrower view of data, and explicit review points around actions that change money, access, customers, or public output.
This is why the page talks about infrastructure, application, and prompt injection together. Runtime isolation reduces platform blast radius. Application controls protect credentials and control paths. Prompt-injection defenses assume some input will be malicious and keep that input away from unrestricted authority.
05
control inventory
implementation controls
The detailed controls stay available for technical review.
Infrastructure security
Reduce blast radius at the deployment boundary.
A production agent should not feel like another tab in a shared app server. The runtime, sandbox, configuration, and storage paths are treated as deployment boundaries, so one workflow can be reviewed, changed, or constrained without widening the whole platform.
Dedicated Worker configuration, named container sandboxes, per-worker storage prefixes, Cloudflare Access for protected surfaces, and suspicious recon monitoring.Application security
Constrain the paths where agents receive authority.
Most practical agent risk shows up in ordinary product paths: a callback URL, a channel token, a rushed redeploy, a chat burst, or an admin action. Those paths need validation and narrow credentials before the model ever gets involved.
AES-256-GCM secret encryption, strict request schemas, HTTPS-only callback validation, private-network callback blocking, rate limits, allowlists, and scoped gateway tokens.Prompt-injection security
Assume untrusted text will try to become instructions.
Prompt injection is not fixed by writing a stronger system prompt. The safer pattern is to make the agent boringly constrained: fewer tools, clearer allowed actions, sandboxed execution, and human review before decisions with money, access, publishing, or customer impact.
Separate untrusted content from privileged instructions, limit tools to the deployed workflow, probe exfiltration and escalation paths, and keep high-impact actions behind review.06
operating posture
deployment review
The review starts with what the agent can read, change, or expose.
Mature security pages are clear about defaults and clear about where implementation depends on the customer. For agent systems, the highest-risk decisions are specific to the workflow, data sources, integrations, and operator roles.
01
Identify credentials, channels, data sources, tools, and roles.
02
Separate runtime, state, access, and allowed actions per deployment.
03
Define approval gates for spend, access, publishing, and customer impact.
04
Probe sensitive flows for injection, exfiltration, and escalation.
07
questions
security faq
Specific answers before a production handoff.
How are production agent deployments isolated?
Each production deployment is designed around a separate runtime boundary, with dedicated Worker configuration, sandbox naming, and per-deployment storage and configuration paths rather than a single shared namespace.
How are API keys and bot tokens handled?
Secrets are encrypted with AES-256-GCM before storage and only decrypted for deploy or runtime operations where the credential is needed.
How is admin access protected?
Protected hosted and admin surfaces use Cloudflare Access policies. Server-to-server control flows use scoped gateway-token authentication rather than broad shared credentials.
How do you handle prompt injection?
Prompt injection is handled as an agent-system risk, not just a prompt-writing problem. We limit tools, isolate execution, separate untrusted content from privileged instructions, require review for sensitive actions, and probe high-risk flows for exfiltration or escalation.
Do you claim SOC 2, ISO, HIPAA, or PCI compliance?
Not on this public page. Customer-specific controls, evidence, and documentation can be reviewed during deployment planning or under NDA, but we do not publish unverified compliance claims.
Can security requirements be customized?
Yes. Deployment planning can include customer-specific access policies, approval gates, data boundaries, logging expectations, security probes, and documentation under NDA.