How to isolate AI agents that have access to company data
An AI agent can turn a document containing hidden malicious instructions, excessive permissions, or a stolen credential into a cross-system incident. Its security boundary includes the model, identity, retrieval path, tools, runtime, memory, network, and credentials.
This guide explains AI agent isolation, its architecture, how to select and verify boundaries, and how Northflank supports managed or customer-controlled deployment.
Isolate an AI agent by giving it a distinct identity and a narrowly authorized path to data, then contain its execution, memory, network access, credentials, and retained evidence independently.
- Authorize each request against both the permissions of whoever started the run and the agent's narrower permissions.
- Put a deterministic policy and retrieval layer between the model and company systems.
- Use short-lived, task-scoped credentials instead of shared keys or developer sessions.
- Isolate code execution, memory, files, and network paths according to the data and action risk.
- Test cross-boundary failures and maintain a separate way to stop runs and revoke access.
AI agents that query internal databases, process private files, or execute code need an isolated runtime and controlled paths to company data. Northflank provides microVM-backed sandboxes, secret injection, RBAC, and audit logs for running these agents alongside the APIs, databases, jobs, and other services they use. Run on Northflank Cloud or use self-serve BYOC to place the agent runtime and workload data plane inside your cloud account.
If your AI agents access company data, Northflank gives you infrastructure controls for isolated execution, workload identity, secrets, private networking, and audit evidence. Your application retains control of which users, tenants, records, and tools each agent is authorized to access.
Get started with Northflank self-serve, or book a demo to discuss architecture, security, compliance, data residency, or migration requirements.
Isolation constrains every path by which an agent can read, retain, transform, or disclose company data. Private model hosting alone does not achieve it.
A container can separate processes while the application retains an unrestricted database credential. A private model can still receive the wrong tenant's records.
Agents can turn data into actions. Indirect prompt injection inside an email, document, or repository can influence retrieval or tool use, so infrastructure must limit what a manipulated agent can reach and change. The guide to deploying agents securely in enterprises covers the broader controls.
| Boundary | What to isolate | Failure it contains |
|---|---|---|
| Identity | User, agent, service, and session | One identity using another's permissions |
| Data access | Records, fields, tenants, purposes, and environments | Retrieval beyond the task's permitted scope |
| Runtime | Code, processes, files, mounts, and compute | Malicious or generated code reaching the host or another workload |
| Memory | Conversation state, vectors, caches, and checkpoints | Sensitive or poisoned context leaking into later work |
| Network | Internal services and external destinations | Lateral movement and data exfiltration |
| Credentials and tools | Tokens, secrets, actions, and parameters | A model converting broad credentials into broad action |
| Evidence and containment | Traces, decisions, revocation, and quarantine | An incident continuing without attribution or control |
The aim is to make permitted paths explicit, narrow, observable, and revocable.
A contained architecture makes authorization decisions outside the model and independently isolates identity, retrieval, runtime, memory, credentials, networking, and audit evidence.
Give the agent its own named workload identity instead of a developer login or shared administrator token. Record both the agent's identity and who or what started the run, such as an employee, application, or scheduled job.
This lets policy evaluate access passed from a user or system to an agent. Scope the agent by task, environment, tenant, and maximum action, and make its access independently revocable. Apply the same principles used to manage access and security for AI-built applications.
On Northflank BYOC, workload identities let services and jobs authenticate to external cloud resources using short-lived tokens instead of stored long-lived credentials.
Do not connect the model directly to a database or shared index. Put a policy service between the agent and each data source to check every retrieval or action before content enters the model context.
The agent's effective access should be limited to what both the requester and agent are permitted to do, with any additional restrictions for the task. Apply tenant, project, geography, data-classification, and environment filters at query time. Preserve source-system permissions where practical instead of rebuilding them as prompt instructions.
Separate read from write paths, use masked development data where possible, and minimize returned fields and records. Treat model output as a request; deterministic policy decides whether it may proceed.
Give each connector a credential for its specific target service and operation. Prefer short-lived tokens, restricted scopes, and workload identity where supported.
For MCP integrations, follow the current MCP authorization specification: validate that tokens were issued for the MCP server as their intended resource, and do not pass a client's MCP access token through to downstream APIs. Obtain a separately scoped token for the downstream resource.
Keep credentials outside prompts, tool results, repositories, logs, and images. Inject them only for approved requests and rotate them independently.
Northflank workloads can use workload identities for short-lived access to external cloud resources, secret injection for credentials that must be stored, and API tokens whose permissions come from an associated RBAC role.
Use a stronger execution boundary for generated code, shell commands, dependencies, user files, or untrusted repositories. The orchestrator should not share its host, filesystem, or privileged credentials. This principle also shapes enterprise AI remote coding environments.
Start with an ephemeral environment, lifetime and resource limits, controlled mounts, and no privileged host access. Add persistence only when required. A microVM reduces reliance on the shared host kernel.
Runtime isolation contains code execution but does not determine which records the agent may retrieve.
Northflank sandboxes provide ephemeral or persistent environments for AI agents and untrusted code. The sandbox documentation describes the microVM-backed isolation boundary used for these workloads.
Treat agent memory as a data store. Histories, vector indexes, caches, files, checkpoints, and tool results can retain sensitive information after a task ends.
Partition stored state by tenant and sensitivity. Define ownership, encryption, retention, deletion, and a record of where the data came from. Validate untrusted content before storing it for future runs, as part of governing AI-built applications at scale.
Northflank sandboxes can remain ephemeral or attach persistent storage when a task requires retained state, but your application must still enforce memory partitioning, retention, and deletion rules.
Allow only required ingress, egress, destinations, and protocols. Use private paths internally and broker outward actions such as email, uploads, and webhooks.
Protect internal address ranges and cloud metadata services. Current MCP security guidance warns that OAuth-related URL fetching can introduce SSRF paths to internal resources and metadata endpoints. Network controls cannot fix prompt injection but can block unapproved destinations.
Keep development, staging, and production on separate network and identity paths. Enforce the boundary in infrastructure, not prompts.
Northflank private networking connects internal workloads without exposing them publicly. On BYOC clusters, network policies provide ingress and egress allow and deny rules between workloads and projects, including outbound rules for specified external destinations.
Record enough evidence to reconstruct a run without collecting unnecessary sensitive content. Correlate identities, versions, source references, tool requests, policy decisions, approvals, affected resources, results, and state changes.
Log prompts and outputs only where policy permits. Correlate platform audit logs with agent traces.
Operators must independently terminate runs, revoke credentials, disable connectors, block network paths, quarantine memory, and preserve evidence.
Northflank audit logs record platform and configuration events, while API tokens can be revoked independently. Correlate these events with application-level agent traces, and keep run termination and memory quarantine in the agent system.
Choose an AI agent's isolation boundary based on the most sensitive data it can reach and the highest-impact action it can perform. A single pattern would under-protect production or burden low-risk retrieval.
| Workload | Recommended boundary | Data pattern |
|---|---|---|
| Read-only knowledge agent | Separate identity, permission-filtered retrieval, tenant-partitioned memory | Approved documents returned under the user's existing access |
| Departmental workflow agent | Dedicated service identity, brokered tools, restricted network, scoped durable state | Department systems with explicit read and bounded-write operations |
| Coding or data agent | Ephemeral isolated runtime, controlled mounts, restricted egress, short-lived credentials | Masked data by default; narrowly approved production access only when required |
| High-impact production agent | Dedicated workload and data boundary, per-action policy, independent containment, complete evidence | Minimal records and operations required for a defined production task |
A sandbox per run may suit untrusted code but not be necessary for a read-only assistant. Require human approval when an action exceeds the permissions already assigned to the agent.
Before production, verify that the boundary prevents cross-user and cross-tenant retrieval, limits credential reuse and egress, separates memory, and supports revocation. Repeat after changes.
Northflank supports isolated agent infrastructure with sandboxes, identity and secret controls, private networking, audit logs, and customer-cloud deployment. Your application remains responsible for record-level authorization and tool policy.
- Execution and access: MicroVM-backed sandboxes, RBAC, scoped API roles, SAML or OIDC SSO, directory sync, MFA enforcement, and secret injection separate workloads, people, and credentials.
- Networking and evidence: Private networking, BYOC network policies, and audit logs provide infrastructure boundaries and platform events.
- Deployment control: Use Northflank Cloud for managed infrastructure or Northflank BYOC to run workloads, databases, and private networking in your cloud account.
- Agent-native operations: Northflank Skills helps coding agents operate services, databases, sandboxes, GPU workloads, previews, and releases through the API and CLI. The agent's credentials and permissions still govern access.
- Compliance: Northflank is SOC 2 Type 2 compliant and HIPAA compliant, with BAAs supported under Enterprise contracts. See Northflank security details.
With BYOC, runtime, databases, storage, private networking, and the application data path can remain in your cloud boundary, while Northflank's hosted control plane retains platform metadata. Review other data flows separately.
Your retrieval broker decides which records the agent may see; Northflank constrains infrastructure access. See Northflank for Enterprise for the wider governance model.
Get started with Northflank self-serve, or book a demo to discuss your architecture, security, compliance, networking, or data-residency requirements.
It depends on the workload. A read-only retrieval agent may not need its own runtime sandbox if identity, data authorization, tenant partitioning, and network controls provide adequate separation. An agent that executes generated code, dependencies, user files, or untrusted repositories needs a stronger runtime boundary. Northflank sandboxes provide microVM-backed environments for these higher-risk workloads on Northflank Cloud or suitable BYOC node pools.
No, a private model alone is not enough to protect company data. Private inference can support data-location requirements, but it does not control retrieval permissions, connector access, retained memory, network egress, or downstream actions. You must secure the complete path between the agent and company data.
Generally, an agent should not directly reuse an employee's permissions. Use the employee's identity to establish maximum scope, then give the agent a narrower identity and task permissions. Northflank's RBAC, scoped API roles, and workload identity can separate platform, API, and cloud-resource access instead of reusing an employee credential.
Use BYOC for private connectivity, infrastructure ownership, regional placement, cloud IAM integration, or defined data-residency boundaries. Northflank BYOC places the agent runtime and application data path in your cloud account, while Northflank's hosted control plane retains platform metadata. Review each associated data flow separately.
Log who or what started the run, the agent and policy version, retrieved-source references, policy decisions, tool requests and results, approvals, affected resources, and state changes. Record prompts and outputs only where policy permits. Correlate application-level agent traces with Northflank audit logs for platform and configuration events.
Use these guides to extend the isolation model across deployment, infrastructure, development, and governance.
- How to deploy agents securely in enterprises: Extend isolation across tools, releases, and incident response.
- How to manage enterprise AI infrastructure: Plan governance and ownership across AI workloads.
- Enterprise AI remote coding environments: Isolate development environments for coding agents.
- How enterprises should govern AI-built applications at scale: Apply access and lifecycle controls at scale.
