Assume the agent can be redirected. Build security that holds anyway.
You have put an elite hacker inside the perimeter
Imagine placing an elite, tireless hacker inside your enterprise. Give them a terminal, access to business systems, and the ability to write and execute code. Then let outsiders send them instructions disguised as emails, documents, customer tickets, and web pages.
That is the threat model you must be prepared for when deploying a code-executing AI agent.
The agent is not inherently malicious. Nor does every model have the capabilities of an elite security researcher. The analogy describes how to design its containment: assume a capable adversary can redirect the agent and use whatever its environment makes available.
This is different from exposing a conventional application endpoint. An agent can interpret unfamiliar material, construct new programs, combine tools, and adapt its next step to what it discovers. A document can influence not just its answer, but its decisions about which files to open, which APIs to call, and where to send the result.
That is the danger of indirect prompt injection. An attacker does not necessarily need an account on your platform. They may only need control over something your agent reads.
For an enterprise, the consequences extend far beyond an embarrassing chatbot response. The agent may handle customer records, employee correspondence, contracts, operational data, or financial workflows. A redirected agent can turn legitimate access into disclosure, an approved integration into an unauthorized action, or a shared runtime into a route toward another user's information.
The critical security question is not whether the agent usually follows instructions. It is what stops it when it follows the wrong ones.
Diagram 1: Outside instructions, inside capabilities
The agent operates inside the enterprise, but some of the content influencing its decisions originates outside it.
"We gave it minimal permissions" is not a containment strategy
Enterprise buyers understandably ask about least privilege. Which systems can the agent access? Are its credentials scoped? Can it operate read-only?
Those are necessary questions. They are not sufficient acceptance criteria.
If an elite hacker had read-only access to confidential documents, would you consider those documents safe? Read-only prevents modification. It does not prevent disclosure. If the same operator could send messages through an approved service, restricting them to that service would not establish that every recipient or payload was authorized.
Consider a hypothetical customer-support agent. Its legitimate job requires reading account information and replying to customers. An attacker supplies a document that instructs it to include an internal account summary in a reply. If the agent follows that instruction, both operations may pass the configured permission checks. The outcome is still a breach.
No administrator account was required. No privilege escalation occurred. The attacker abused the authority the task already needed.
Diagram 2: A harmful outcome using permitted operations
The operations are permitted; the use of the information is not.
The gap becomes larger when the agent can execute code. Narrow API scopes do not restrict every file visible to its process, every localhost service it can reach, or every destination available through its network stack. Per-user credentials do not automatically separate the users whose sessions and memory share a platform.
Least privilege reduces the available authority. It does not establish task intent, credential custody, tenant isolation, execution containment, or safe rendering of the result.
Treating minimal permissions as the complete security strategy leaves the most important question unanswered: what contains the operator using those permissions against you?
Zenera's starting point: assume compromise, enforce boundaries everywhere
Zenera's security architecture starts from an adversarial assumption: the reasoning can be redirected, and untrusted execution may be compromised. Protection must not depend on the model deciding to respect its own boundaries.
That means zero trust inside the system, not just at its perimeter.
A request does not become trustworthy because it came from an internal IP address. A developer does not inherit access to every user of the application they develop. A project workload does not need the platform's signing keys. A saved report does not become safe browser code because the platform generated it.
Zenera separates these responsibilities across independently enforced boundaries:
- Enterprise identity and an authenticated edge establish who is calling.
- The Control Plane checks access and signs scoped internal requests.
- Project and user isolation constrain which state is visible.
- Credential brokers retain long-lived secrets outside project workloads.
- Disposable sandboxes constrain untrusted code and host-kernel exposure.
- Default-deny networking constrains internal reachability and external destinations.
- Browser isolation separates untrusted artifacts from the authenticated portal.
These are complementary controls. Not every attack crosses every boundary. The objective is to ensure that compromising one component does not automatically grant the authority and access held by the others.
Diagram 3: Trust is checked at each boundary
Identity, authority, data, credentials, execution, networking, and presentation have distinct enforcement responsibilities.
Prove authority at every hop, including localhost
Suppose Alice uses an enterprise assistant while Bob develops that assistant. Bob has terminal access to the project's developer environment. That must not grant him access to Alice's conversations, memory, or connected accounts.
This is not only an external-access problem. Containers in the same Kubernetes pod share a network namespace. A sibling developer container can reach services listening on loopback. Pod-to-pod network policies do not turn those localhost calls into authenticated requests.
Trusting 127.0.0.1, a project IP, or a header claiming Alice's identity would confuse location with authority.
Zenera establishes identity at the gateway, strips caller-supplied identity headers, and forwards verified claims with gateway verification. The Control Plane then checks project access and thread ownership before authorizing a downstream request.
For internal authorization, Zenera uses Ed25519 signatures. The private signing key remains in the Control Plane. Project services receive the public verification key.
That separation matters. With a shared HMAC signing secret, a component that obtains the verifier's secret can also mint tokens. With Ed25519, possession of the public verification key does not grant signing authority.
A conceptual request-bound token carries context such as:
{
"iss": "control-plane",
"aud": "agent-runtime",
"sub": "user_alice",
"prj": "project_alpha",
"thr": "thread_4412",
"req": "POST /api/sessions/thread_4412/runs",
"iat": 1793167200,
"exp": 1793167260
}The receiving service must verify more than the signature. It pins the expected signing algorithm, checks issuer and audience, enforces expiry, validates project and user/thread context, and matches the HTTP method, path, and query string against the authorized request.
A token for reading one thread must not authorize deleting it, accessing a different thread, or calling a different service. Zenera's documented request-token lifetime is 60 seconds, limiting the validity window.
Short-lived and request-bound does not mean single-use. Preventing replay of the exact same request within that window requires an additional mechanism, such as nonce tracking. Likewise, a signed identity is not a substitute for correct ownership checks.
Diagram 4: Reachable does not mean authorized
A public verification key lets the project validate authority without granting it the power to impersonate users.
Keep the enterprise's keys outside the agent's reach
A contained adversary should not find long-lived enterprise credentials waiting in environment variables.
Zenera separates OAuth connection from agent execution. The initial authorization flow runs between the browser, Control Plane, OAuth Broker and Vault, and external provider. The project workload does not handle the OAuth callback or retain the refresh token.
During execution, the trusted runtime requests access for a verified user context. The broker derives project and user identity from Control-Plane-signed claims, not from a submitted user ID or the caller's network address.
This addresses a critical multi-user failure mode: Bob's terminal cannot obtain Alice's integration token merely by sending Alice's identifier to an internal endpoint.
The Control Plane strips refresh credentials before returning temporary access. Short-lived access tokens are used in runtime memory rather than persisted in project files or environment variables. Refresh tokens and OAuth client secrets remain outside the project workload.
Model credentials follow a similar separation. The LLM Gateway holds upstream provider keys; project workloads receive project-scoped virtual keys rather than the platform's master credentials.
Diagram 5: Separate credential custody from execution
Long-lived credentials stay in the broker boundary. Temporary access is tied to verified execution context.
This limits credential exposure; it does not eliminate credential risk. An access token can still be abused while valid. Keeping it in a local variable does not guarantee immediate secure erasure when a handler exits. Runtime compromise remains consequential.
The benefit is architectural: a shell-level compromise does not automatically yield persistent account access or platform-wide model credentials.
Contain users, files, execution, and the kernel
The elite hacker analogy becomes especially useful when evaluating a shell tool. A shell is not one business capability. It is an interface to general-purpose computation.
Zenera therefore separates trusted runtime services from untrusted execution and applies several different boundaries.
Separate projects and users within projects
Each project has its own workload and separated storage. Within a shared agent, user sessions, run histories, and memory require their own access boundaries.
Development tools can receive project code without receiving the user-state partition. That partition is not mounted into the Developer Web IDE or Workspace Manager. A developer's terminal cannot browse a directory that is absent from its mount namespace.
An execution sandbox receives only the current user and thread's workspace, not the parent directory containing everyone else's state. System audit logs are excluded from that writable task workspace.
These filesystem boundaries complement request authorization. Protecting API access while exposing the same information through a shared mount would defeat the purpose.
Make execution disposable and resource-bounded
A dedicated sandbox engine creates per-turn execution containers and destroys them after the turn. CPU and memory caps constrain resource exhaustion. Separate storage for sandbox images and writable layers reduces the risk that execution activity fills application and user-state filesystems.
Application containers run without root privileges, and project workloads do not automatically receive Kubernetes service-account tokens.
Disposability limits process persistence. It does not undo a message already sent or remove malicious instructions preserved in a persistent document or memory store. Persistent state remains part of the threat model.
Reduce exposure to the host kernel
Standard containers use Linux namespaces, capabilities, cgroups, and syscall filtering, but still depend on the host kernel. For arbitrary, potentially adversarial code, that shared kernel is an important attack surface.
Zenera places gVisor's runsc runtime at the child-sandbox boundary. Its Sentry implements a user-space kernel that handles guest system calls, reducing direct exposure to host-kernel interfaces. The Gofer brokers filesystem access to the scoped workspace. The systrap platform supports syscall interception without requiring hardware virtualization.
This placement leaves trusted project services outside the nested gVisor boundary while applying additional isolation where untrusted code executes. It also avoids making the entire project environment depend on support for nested container operations inside an outer gVisor sandbox.
Diagram 6: Isolation at the untrusted execution boundary
Isolation must constrain what the code can see, what resources it can consume, and which host interfaces it can exercise.
gVisor is an additional isolation boundary, not a proof of invulnerability. The sandbox engine, runtime configuration, host, and platform services still require hardening and maintenance.
Control what the compromised agent can reach
A sandbox that can send sensitive data anywhere on the internet is isolated in only one sense.
Zenera combines default-deny network policies with explicit permitted paths. At Layers 3 and 4, Kubernetes policies constrain ingress and egress by workload, destination, and port. Project workloads must not freely scan neighboring projects, internal databases, the cluster API, or cloud instance metadata services.
Private and link-local destinations are restricted, with explicit exceptions for required internal dependencies such as DNS and the LLM Gateway. Disabling service-account token mounting removes another source of ambient cluster authority.
Outbound HTTPS needs more scrutiny. Allowing port 443 broadly lets an attacker use the same encrypted transport as a legitimate integration.
Cilium adds DNS-aware destination control. Approved FQDN resolutions populate permitted destination IPs, while DNS query rules constrain which names can be resolved through the approved path. Unapproved destinations are denied unless another policy allows them.
These controls are more precise than "internet access enabled," but their limits matter. FQDN policies operate through resolved destinations; shared hosting and permitted IPs complicate the relationship between a domain and the service reached. HTTP path or payload inspection inside HTTPS requires an appropriate proxy or TLS-termination arrangement, not just a DNS allowlist.
Most importantly, an approved service can still be an exfiltration channel. An attacker may control a recipient on an approved messaging platform or a repository on an approved development service.
Network policy answers whether a destination is reachable. Application authorization must still answer whether this operation, account, recipient, and payload are allowed.
Diagram 7: Destination control is one gate, not the final verdict
An approved destination must not become blanket permission to disclose information through it.
Do not let hostile output become trusted portal code
The last boundary is easy to overlook: the person inspecting the agent's work.
An attacker-controlled document may become part of a run report or memory artifact. If that artifact is rendered as trusted HTML in the authenticated portal, the attack can move from the agent's context into the operator's browser.
Zenera's report-rendering approach separates these concerns. Ownership checks govern access to the thread. A sandboxed iframe with allow-scripts, but without allow-same-origin, places report content in an opaque origin rather than the portal's origin. The frame does not receive permission for forms, popups, or top navigation.
A restrictive Content Security Policy on the rendered report constrains resource loading and network connections, including connect-src 'none' and data-only images. These restrictions must cover the actual report document; a sandbox attribute alone is not a network-denial policy.
Diagram 8: Untrusted output stays outside the portal origin
Storing or displaying an artifact does not make its contents trustworthy.
Replace the permission checklist with a containment test
Enterprise buyers should still demand least privilege. They should also demand evidence that the architecture holds when the agent behaves adversarially.
The useful evaluation is not another screenshot of scoped permissions. It is a set of attempted boundary crossings:
- Redirect the agent through an untrusted document. Identify which data, tools, and destinations remain available. Distinguish preventing the injection from containing its consequences.
- Try another user's session from a developer terminal. Test both runtime endpoints and filesystem access. Verify that localhost and project membership do not substitute for ownership.
- Repurpose an internal authorization token. Change the method, resource, audience, or project. Test exact-request replay separately rather than assuming request binding prevents it.
- Inspect credential exposure. Determine whether the sandbox can obtain refresh tokens, OAuth client secrets, or upstream model keys. Check temporary credentials and logs as well as environment variables.
- Exercise execution and network boundaries. Test unrelated file access, resource limits, metadata reachability, neighboring workloads, unapproved DNS queries, and direct-IP egress.
- Use an approved service as the attempted disclosure channel. Test an unauthorized recipient or attacker-controlled account. A domain allowlist is not a passing result.
- Open a hostile report. Verify that its code cannot access the portal's session state and that its resource and connection restrictions actually apply.
For every result, ask which component enforced the decision. Was it a model instruction, an application check, a cryptographic verifier, a mount boundary, a sandbox, a network policy, or a browser control? What happens if the component on the other side is compromised?
That is the difference between a feature checklist and a security architecture.
Secure the architecture for the agent you cannot trust
The elite hacker analogy is uncomfortable because it changes the buying question. Instead of asking only whether the agent has too much access, it asks whether the environment can withstand hostile use of the access it genuinely needs.
Minimal permissions answer how much authority an agent receives. Enterprise security must also answer what happens when that authority is used against you.
Zenera's approach is to enforce boundaries throughout the system: verified identity at the edge, scoped authority between services, separated user state, isolated credential custody, disposable execution, reduced host-kernel exposure, controlled networking, and untrusted-content isolation in the browser.
No single layer makes an agent safe. The strategy is to prevent one redirected reasoning loop from automatically inheriting the trust, secrets, data, and reachability of the whole enterprise.
Do not build your security case around the agent continuing to behave. Build it around the boundaries that remain when it does not.
Explore Zenera's security architecture, or request a technical discussion about the trust boundaries in your enterprise deployment.