How to govern AI-agent code execution in enterprise environments

An AI agent can move from suggesting code to running shell commands, installing dependencies, changing files, and calling internal services in one workflow. Risk appears when that temporary execution inherits a developer's credentials, a shared worker's network access, or a path to production.

Governance needs to cover the complete execution event, not only the model's response. This article explains how to control who starts a run, what enters it, where it executes, what it can reach, what evidence it produces, and how your operators stop it.

Govern AI-agent code execution by putting every run inside a policy-controlled, isolated, time-bound environment with scoped identity, data, networking, resources, evidence, and containment.

• Register each execution path with an owner, approved purpose, target environments, tools, data classes, network destinations, resource limits, and shutdown procedure.
• Authorize each run from its initiating identity, agent identity, requested action, code provenance, target, and delegated authority.
• Run generated or untrusted code away from the agent orchestrator and shared application workloads, using a boundary proportionate to the risk.
• Issue short-lived credentials and allow only the files, secrets, services, and external destinations required for that task.
• Record policy decisions and effects, then test escape, escalation, exfiltration, persistence, and approval-bypass paths before increasing autonomy.

Governing AI-agent code execution means enforcing the conditions under which an agent may run code, from admission through termination.

An enforceable policy layer outside the agent should decide whether execution is permitted and constrain environment creation, access, limits, and evidence retention.

Use the following execution classes as a practical framework, not a fixed industry standard:

Treat transitions between classes as new authorization decisions. Passing sandbox tests should not grant permission to deploy the result.

Before execution, establish ownership, verify the request, and decide whether the code and its inputs are eligible to run at all.

Inventory agents that can invoke a shell, interpreter, build system, notebook, or execution API. Record the owner, approved job, environments, tools, data classes, destinations, persistence, runtime, and containment procedure.

Inventory the route, not just the product. Local, CI, and support agents can create different identity and network paths.

If execution classes need harder network boundaries, Northflank lets your platform team separate workloads into self-contained projects. This creates an organizational and default network boundary without treating project placement as authorization.

Authenticate the initiator, then evaluate the agent's narrower authority against the operation, code origin, target, affected resources, data class, and time window.

Do not let an agent inherit a developer session or shared administrator token. An agent testing a branch does not need production database or organization access.

If agent access needs to follow enterprise identity policies, Northflank supports SAML or OIDC SSO, directory sync, and MFA enforcement. Your platform team can use RBAC and scoped API roles to control which projects and actions each identity can reach. See secure enterprise agent deployment for the wider architecture.

Treat code, commands, images, manifests, build scripts, repositories, and tool responses as inputs. Establish provenance where practical, pin approved artifacts, and use controlled registries.

Treat repository files, tickets, webpages, logs, tool responses, and retrieved documents as potentially adversarial instructions. Authorize the resulting operation, not the source of the instruction.

Run secret, dependency, image, and static checks when they fit the workload. Scanning can find known problems, but it cannot prove that generated code is safe. Runtime containment remains necessary.

For functional review, a Northflank Preview Blueprint creates an isolated full-stack deployment for a branch or pull request. This connects execution governance to a separate development and production path.

The runtime should assume the code may be wrong or hostile and constrain its effect independently of model behavior.

Run generated code outside the orchestrator and shared workers, with its own filesystem, resources, lifecycle, and identity.

A conventional container may suit a low-risk, single-tenant task with trusted code and tightly restricted inputs and privileges. Prompt-generated code, untrusted repositories, user files, or new dependencies may justify a separate-kernel boundary such as a microVM.

Generated or untrusted code can run in Northflank sandboxes with strong workload isolation on Northflank Cloud. Compare the wider requirements for running AI-generated code securely at scale.

Start without ambient credentials. After policy approval, issue short-lived access and inject only the secret, file, or dataset the task requires.

Keep development and production credentials distinct. Give test runners sandbox integrations and approved test data. Scope access to a company service by operation and resource.

For runtime credentials, Northflank secret groups inject selected values into specific workloads. Data authorization still belongs in the application, as explained in how to isolate AI agents that access company data.

Begin with no inbound access and no unnecessary egress. Explicitly allow required registries, source hosts, model endpoints, and internal APIs.

Keep cloud metadata services, cluster control planes, credential endpoints, production databases, and unrelated internal networks unreachable. Route required outbound actions through a controlled service when the destination or payload needs validation. Network policy cannot prevent prompt injection, but it can stop an injected command from reaching an unapproved target.

If your execution layer runs in BYOC, configure Northflank network policies as allowlists or deny-all rules. With no rules, traffic is allowed in that direction. This differs from default project isolation. For approved private routes, follow the same principles used to connect AI-built applications to private corporate APIs.

Set deadlines and CPU, memory, storage, process, and output limits to contain runaway processes and cost.

Default to ephemeral storage. Persistent state needs an owner, retention period, access policy, and deletion path. Termination should remove the runtime and revoke access.

For resumable state, Northflank sandboxes can attach a volume and manage compute and storage separately. Compare the lifecycle choices in persistent versus ephemeral AI sandboxes.

Approval should follow authority and impact, not interrupt every agent action.

Policy can allow low-risk tests in a restricted sandbox. Medium-risk operations may require checks against an approved repository, command family, environment, and change window.

Use independent authorization for production deployments, destructive data changes, privileged identity changes, secret access, disabling security controls, or multi-tenant effects.

Show the versioned artifact or proposed operation, target, effective permissions, expected effect, and recovery path. Bind approval to that operation and expire it to prevent replay.

If agent-generated changes need a controlled route to production, Northflank Workflows can connect builds, deployments, jobs, backups, conditions, and proportionate approvals. This keeps authority in the release process rather than the agent session.

Enterprises should retain enough evidence to reconstruct why a run was allowed, what it did, and what changed without collecting unnecessary sensitive content.

Correlate the initiator, agent and policy version, artifact digest, environment, policy decision, credentials, destinations, commands, approvals, affected resources, result, resource use, and termination reason. Record inputs and outputs only where policy permits, without chain-of-thought.

Application traces should capture policy-relevant action selections, tool calls, tool results, and execution outcomes. Platform audit logs should capture access, infrastructure, build, and deployment changes. Connect them with a run or trace ID.

If your security team needs the platform side of that evidence, Northflank audit logs record event type, triggering identity, source, timestamp, parent events, and resource-scoped platform changes. Agent commands and tool results still require application traces.

Before widening access, test malicious inputs, prompt injection, malformed commands, escalation, secret discovery, disallowed egress, resource exhaustion, persistence, approval bypass, replay, and sandbox escape. Use the results to decide whether authority can increase.

Containment must operate independently of the agent and the systems it controls.

Your operators should be able to terminate the runtime, revoke issued credentials, block its network paths, disable the relevant tool or policy, quarantine persistent state, preserve evidence, and prevent another run from starting. Test this sequence while a task is active, including the behavior of child processes and asynchronous jobs.

Stopping the model does not stop every effect. Queued deployments, background processes, issued tokens, or external API requests may outlive the conversation and require separate containment.

If each run needs an independent lifecycle, a Northflank sandbox can be paused by scaling it to zero or destroyed through the API, with persistent volumes removed separately when the incident procedure permits it.

Northflank brings the controls used throughout this article into one platform for agent sandboxes and the APIs, jobs, databases, and release workflows around them. Northflank for Enterprise adds the organization-level identity and governance layer, while your application retains responsibility for deciding which command, tool, or business record an agent may use.

Teams can create sandboxes through the Northflank API or JavaScript client, restrict access with RBAC, control BYOC egress through network policies, and correlate platform audit events with agent traces. Preview environments and Workflows give validated outputs a separate route to production.

Use Northflank Cloud for managed infrastructure. If workloads need to run inside your cloud account with its network controls and regional placement, use Northflank BYOC. Workloads run in your cloud environment, while Northflank-hosted control-plane metadata remains outside that workload boundary.

These answers address common decisions when enterprises introduce agent-controlled runtimes.

It depends on the code and impact. A container may suit low-risk, single-tenant automation with trusted code and restricted inputs and privileges. Generated or untrusted code may require a separate-kernel boundary. Northflank provides sandboxes with strong workload isolation on Northflank Cloud.

No. Low-risk, reversible commands can run under policy. Require independent authorization for higher-impact actions. Northflank Workflows can add conditions and approvals to agent-generated releases.

Not on its own. Northflank BYOC runs agent workloads in your cloud environment, but you still need scoped access, isolation, egress controls, evidence, and containment.

No. A sandbox does not stop a model from following malicious instructions. It limits the systems, credentials, files, network paths, and resources that manipulated code can reach, reducing the resulting blast radius.

Use these guides to extend execution governance across data, deployment, environment design, and scale.

• How to isolate AI agents that have access to company data
• Which platform is best for running AI-generated code securely at scale?
• How to deploy agents securely in enterprises
• How enterprises should separate development and production for vibe-coded apps
• How to run millions of concurrent AI sandboxes