Enterprise Guardrails
for AI Agents

The Problem: Powerful Agents, Zero Guardrails

In March 2026, an AI coding agent wiped 1.9 million rows from a production database, including the backups. Every command the agent executed was technically correct. It simply didn't know it was operating on a live system, because the knowledge that distinguished real infrastructure from temporary copies existed only in the engineer's head.

This wasn't a freak accident. It's the predictable outcome of running powerful autonomous agents with no structural guardrails. The agent was running on a developer's laptop with full system access: production credentials, live databases, deployment pipelines, all reachable with no approval process in the way.

The core issue isn't agent intelligence. It's agent governance. AI agents are excellent at executing tasks. They are terrible at understanding which tasks should never be executed without human judgment. And the more capable agents become, the more damage they can do when operating without boundaries.

CoderFlow was built to solve this problem. Not by limiting what agents can do, but by controlling where they do it and requiring human approval before anything leaves the sandbox.

Container Isolation: Agents Can't Reach Production

Every CoderFlow task runs inside an isolated Docker container with no privileged access. Agents physically cannot reach systems they aren't explicitly granted access to.

• One container per task: Each task spawns a dedicated container with its own filesystem, network context, and resource limits. Tasks cannot access each other's processes or data.
• Non-root execution: All agent commands execute as the coder user (non-root). No privilege escalation is possible.
• Read-only mounts: Sensitive files, setup scripts, and cleanup scripts are mounted read-only. Agents can read what they need but cannot modify system-level resources or alter their own execution environment.
• No Docker socket access: The Docker socket is never mounted into task containers, preventing container escape via the Docker API.
• Preserved for inspection: Containers are kept after task completion for audit and debugging, not auto-removed.

Admin-Defined Deployment Profiles

Deployments in CoderFlow are not freeform commands. They are structured, admin-defined profiles that execute predetermined steps with full tracking.

• Admin-defined profiles: Deployment profiles are created by administrators as shell scripts with metadata. Developers and agents trigger them; they don't write them.
• Isolated execution: Each deployment runs in its own container, separate from the agent's workspace, preventing interference between build and deploy steps.
• Full history: Every deployment records which profile was used, who triggered it, all parameters, complete output, and the exit status. History is maintained per-environment with a configurable retention policy.
• Permission-gated: Only users with the deployments:execute permission can trigger deployments. This permission is granted per-environment through the RBAC system.
• Branch protection: Commits target specific branches, and agents can create new branches to prevent accidental overwrites of protected code.

Git as an Immutable Safety Net

Every code change flows through Git with layered credential management and provider-side enforcement of branch protection rules.

Token resolution hierarchy

Git credentials follow a resolution hierarchy: User OAuth tokens take precedence, falling back to Team Providers, and then Server Providers. This ensures the right credentials are used for the right context, and that no single credential grants broader access than intended.

Provider-side enforcement

CoderFlow works within your existing Git provider's security model, not around it:

• Branch protection rules enforced by GitHub/Azure DevOps apply to all pushes, including those from CoderFlow containers
• Required pull request reviews add a second human approval touchpoint through your existing review process
• Required status checks ensure CI/CD pipelines pass before code is merged
• Repository selection is explicit; repositories not granted to the App are completely invisible to CoderFlow

Credentials are never stored in code or patches. They're resolved at execution time by the platform. Per-repository token selection ensures different repos can use different credential sources.

Read-Only AI Review

Not every AI interaction needs write access. CoderFlow's judge tasks give AI agents read-only access for code review, analysis, and validation, without any ability to modify repositories.

• Strictly read-only: Judge tasks can analyze code, evaluate quality, check for security issues, and provide recommendations, but cannot make any changes.
• Parallel evaluation: Multiple judges can evaluate the same work simultaneously, comparing approaches and flagging concerns from different perspectives.
• Feeds into approval: Judge output is presented alongside code changes in the review interface, giving human reviewers AI-assisted analysis without AI-driven modification.
• Separate audit records: Judge tasks produce their own audit trail, distinct from modification tasks, so it's always clear which AI interactions were advisory vs. productive.

Defense in Depth: Multiple Layers, No Single Point of Failure

CoderFlow's security architecture is not one guardrail. It's multiple overlapping layers. Any single layer would significantly reduce risk. Together, they create a system where catastrophic agent failures are structurally prevented, not just discouraged.