Information Security · Workload Containment

Zero-Trust Security and WebAssembly Sandboxing for Autonomous AI Workloads

1. The threat model of tool-using AI agents

Traditional web application security relies on strict separation between code and data: parameterized SQL queries ensure user input is never interpreted as SQL syntax, and Content Security Policies (CSP) prevent injected strings from executing as browser JavaScript. Large Language Models invert this paradigm. In an LLM, system instructions and untrusted external data (emails, web pages, uploaded resumes, vendor invoices) are concatenated into a single sequence of tokens.

When an AI agent is granted access to external tools or code interpreters, three high-severity attack vectors emerge:

• Indirect Prompt Injection: An attacker embeds adversarial instructions inside a document that the agent is scheduled to summarise or audit (for example, white-on-white text in a PDF invoice instructing the agent to export the last ten database records to an external URL).
• Sandbox Escape via Code Execution: Analytics and data-science agents frequently generate Python, SQL, or JavaScript snippets to aggregate numbers or plot charts. If that generated code executes inside a shared container with ambient environment variables, a single malicious snippet can read cloud provider credentials (`AWS_SECRET_ACCESS_KEY`, database connection strings) from `process.env`.
• Cross-Tenant Context Bleed: In multi-tenant SaaS deployments, shared vector caches or unpartitioned session stores can inadvertently return embeddings belonging to Tenant B when answering a query from Tenant A.

2. Solving the Confused Deputy problem with capability tokens

In classical computer security, a Confused Deputy is a privileged program that is tricked by a less-privileged caller into misusing its authority. Most poorly designed AI backends run as a single privileged service account that holds a master API key to the database, storage buckets, and internal microservices.

At TICNES AI, our zero-trust agent architecture eliminates ambient authority altogether:

1. Short-lived, user-scoped JWTs: When a user initiates an agent task, the orchestrator mints an ephemeral cryptographic token (valid for at most `120 seconds`) carrying the exact `tenant_id`, `user_id`, and an explicit list of permitted tool scopes for that specific task.
2. Downstream policy enforcement: Every tool gateway and database proxy verifies this token cryptographically and applies Row-Level Security (RLS) scoped to `tenant_id`. The agent runtime never holds a master database credential; it cannot query rows outside the caller’s tenant partition even if completely compromised by prompt injection.
3. Taint tracking across untrusted ingestion: Once an agent node ingests untrusted external content (such as an unverified third-party document or web page), its session state is marked as `tainted = true`. While tainted, the policy engine automatically revokes access to any outbound communication or state-mutating tool unless a human explicitly approves the action.

3. WebAssembly and microVM sandboxes for generated code

When an analytical agent needs to execute generated code — such as computing statistical regressions over a CSV file or validating complex statutory date arithmetic — running `exec()` inside the host Node.js or Python process is strictly prohibited.

Instead, we execute agent-generated code inside ephemeral, capability-based WebAssembly (WASM) runtimes (or hardware-isolated microVMs for native scientific libraries) governed by strict resource quotas:

Because the WASM module has no network socket imports and no access to environment variables, even arbitrary code generated by a hostile prompt cannot exfiltrate data or inspect host secrets. The sandbox receives only the serialised input array, performs the calculation within its fuel budget, returns a serialised JSON result, and is immediately destroyed.

4. Preventing data exfiltration via strict egress and markdown sanitisation

One of the most subtle exfiltration vectors in LLM applications is Markdown Image Exfiltration. If an attacker tricks an agent into outputting ``, and the frontend renders that markdown directly in the user’s browser, the user’s browser will automatically issue a `GET` request to `attacker.example`, leaking the sensitive text in the query string without the agent ever making an outbound server call.

To close this vector across all TICNES AI interfaces:

• Our frontend markdown renderers strip arbitrary external image tags (`<img>`, `![...]`) from model outputs, allowing only relative local assets or pre-signed URLs from our own origin.
• A strict HTTP `Content-Security-Policy` (`img-src 'self' data:; connect-src 'self'`) blocks unauthorized browser-side beacons at the network layer.
• Outbound links generated by an assistant are validated against the retrieved citation allow-list; any unverified URL is rendered as plain, non-clickable text with an explicit warning badge.

5. Immutable telemetry and automated anomaly isolation

Every tool invocation, token consumption spike, and policy rejection across our platforms is written to an append-only security log carrying the cryptographic hash of the preceding log entry. Our automated monitoring rules watch for behavioural indicators of compromise — such as repeated citation validation failures, unexpected spikes in token velocity, or attempts to invoke disallowed tool parameters — and can isolate an affected session in under `4.5 seconds`. For a complete overview of our encryption and incident-response standards, see our Security Whitepaper.