Security by Design: Agent Isolation Architecture
Autonomous agents that can't interfere with each other — not by policy, but by construction.
Overview
When you run autonomous workflow agents at scale, the question isn't if something will behave unexpectedly — it's whether your architecture can contain it when it does. Our system is built around hard isolation from the ground up: every agent runs in its own sandboxed runtime with no shared memory, a clearly defined request path, and a complete teardown when decommissioned. Security isn't a feature you configure. It's how the system works.
The Trust Boundary Chain
Every request travels through a fixed sequence of boundaries before an agent takes any action. Nothing skips a step.
Each boundary is a verification and logging checkpoint — not just a logical separation.
What Each Layer Does
API
The authenticated entry point. All requests are validated and authorised here before anything else happens. Unauthenticated or malformed requests go no further.
Orchestration Layer
Routes each request to the appropriate agent, enforces scope, and logs the handoff. This layer is the only part of the system that can dispatch agents — agents cannot spawn or call each other directly. Every dispatch is auditable.
Agent
Runs in a fully isolated sandbox with no shared memory. Each agent is scoped only to the downstream tools it needs for its specific workflow. An agent handling a git operation has no access to the ticket tracker, and vice versa.
Downstream Tools
Agents interact with external tools — ticket trackers like Jira or Linear, git hosts like GitHub or GitLab, and internal tooling — only through explicitly permissioned connectors scoped to that agent.
Isolation Properties
Sandboxed runtimes
Each agent runs in its own isolated execution environment. A misbehaving agent cannot access another agent's process space, cause interference, or trigger downstream actions outside its defined scope.
No shared memory
There is no global state. Information moves between layers only through explicit, logged handoffs — never through shared objects or side channels.
No direct agent-to-agent calls
Agents are dispatched exclusively by the orchestration layer. They cannot invoke each other, which eliminates a common source of unpredictable cascading behaviour in multi-agent systems.
Scoped tool access
Each agent can only reach the specific downstream tools it is explicitly permitted to use. Tool access is defined at dispatch time, not inherited from a global permission set.
Agent Lifecycle & Data Teardown
Agents are created and managed through the Hub — where you set up projects, configure agents, and manage your account. When an account user decommissions an agent through the Hub, all credentials and data provisioned to that agent are immediately removed from its environment:
- Repositories — removed from the agent
- SSH keys — removed from the agent
- API keys — removed from the agent
Credential records remain safely stored in the Hub and can be provisioned to a new agent at any time. The agent's working environment is gone entirely.
This means credentials are never left dormant on a decommissioned agent. There is nothing to rotate, revoke, or clean up manually.
What Agents Log
Agents are designed to log the minimum necessary for operational visibility and auditability — nothing more.
Each agent logs:
- Status updates — whether it is actively working or waiting for a task
- The ticket that was worked on
- The pull request that was created
Agents do not log:
- The full prompt sent to the agent
- Internal reasoning or decision steps
- Any data beyond the task reference and outcome
This is intentional. The prompt and reasoning are never stored anywhere in the system.
What Gets Written to Your Pull Request
When an agent completes a task, it adds a structured summary directly to the pull request:
- What was worked on — a clear description of the task the agent addressed
- What has changed — a summary of the changes made
This gives your team full visibility into what the agent did, directly in your existing code review workflow — without needing to query logs or external systems.
What This Means in Practice
For engineers building on the platform:
- Agents fail independently — a crash or timeout in one workflow has no effect on others
- Tool access per agent is explicit, making integrations predictable and easy to audit
- PR summaries mean agent work is reviewable in the same place as human work
For security and compliance teams:
- Decommissioned agents leave no credentials behind — teardown is total
- Prompts and reasoning are never stored, reducing data exposure surface significantly
- Every orchestration dispatch is logged with full context
- GDPR-sensitive workflows can be isolated to dedicated agents with no risk of data bleeding across workflows
- Isolation is structural — it does not depend on developer discipline or runtime configuration
GDPR & Data Containment
Agents operate in isolated sandboxes with no shared memory. Personal data never moves outside its intended workflow by accident. The orchestration layer ensures data is scoped before it reaches an agent, and agents interact with external tools only through permissioned, logged connectors.
Critically, prompts and internal reasoning are never persisted. When an agent is decommissioned, all associated credentials and working data are permanently removed. This architecture supports data minimisation and purpose limitation requirements without relying on application-level controls alone.
FAQ
- Can an agent trigger another agent?
No. Only the orchestration layer can dispatch agents. Agents have no mechanism to invoke each other directly.
- What happens if an agent crashes?
The failure is contained to that agent's sandbox. The orchestration layer detects it, logs it, and can retry or escalate without affecting any other running agents.
- Are prompts stored anywhere?
No. The full prompt and internal reasoning are never stored anywhere in the system. Only the task reference (ticket) and outcome (pull request) are logged.
- What happens to credentials when an agent is decommissioned?
When an agent is turned off through the Hub, all credentials provisioned to that agent — SSH keys, API keys, and repositories — are permanently removed from the agent's environment. The credential records themselves remain safely stored in the Hub, ready to be provisioned to a new agent when needed. Nothing is left dormant on the agent.
- How is tool access controlled?
Each agent is granted access only to the specific tools required for its workflow, scoped at dispatch time by the orchestration layer. There is no global permission set that agents inherit from.
- How is everything audited?
Every step in the chain — API entry, orchestration dispatch, agent actions, and tool interactions — is logged. Logs are available for review and export for compliance purposes.