Software Factory Security
Software factory security is the practice of governing the AI coding agents that write, test, and ship code: each agent gets a delegated identity, actions are denied by default, every call is checked against policy outside the model, humans approve risky steps, and every decision is logged. This section is for platform, security, and engineering leads who run, or are about to run, a fleet of coding agents.
What a software factory is
A software factory is an engineering setup where fleets of AI coding agents pick up tickets, write code and tests, review, and open pull requests, while people approve at checkpoints such as merge and deploy. The agents run in IDEs (Cursor, VS Code), CLIs (Claude Code, Codex, Gemini CLI), CI pipelines, and cloud background jobs, often many loops in parallel.
In defense and government, "software factory" also names a DevSecOps platform of pipelines and accredited environments, such as Kessel Run or Platform One. These pages use the AI coding agent meaning. The controls apply to those platforms too, once agents commit code inside them.
Why the default setup is risky
Most coding agents run as the developer, with the developer's tokens, and nothing in between asks whether a given action should happen. Five problems follow:
| Problem | What happens |
|---|---|
| Borrowed credentials | The agent inherits SSH keys, cloud CLI profiles, GitHub tokens, and .env files. Nothing scopes them to the task. |
| Standing keys | CI and background agents get long-lived, broad tokens because that is the fastest way to make them work. |
| Prompt injection | Issues, PR descriptions, READMEs, changelogs, and MCP tool responses become instructions once an agent reads them. |
| Confused deputy | The agent holds real authority and can be steered into using it for someone who has none. Authentication does not help: the agent is who it says it is. |
| No attribution | Logs say "the developer did it". You cannot tell which agent acted, who delegated the task, or what the agent said it was doing. |
Sandboxes limit where code runs. They don't decide which credentials, tools, destinations, and data an agent may use for a task. That decision needs an identity per agent and a policy check per call.
The five controls
- A delegated identity per agent. Each agent identity binds the human who delegated the work, the client the agent runs as, the workflow, and the intent the agent declared. Revoking the human revokes every agent acting for them.
- Deny by default. Agents start with no access. You allow destinations, tools, and paths per workflow, not per developer.
- A policy check on every call, outside the model. Every outbound call, MCP tool call, and protected API call gets a decision from a policy decision point (PDP) that the model cannot talk to.
- Human approval at risky checkpoints. Merge to protected branches, production deploys, secrets, production data, and package publishing stop for an approver. Everything else runs on trust levels.
- One decision log. Every allow and deny is recorded with the human, the agent, the action, the resource, the outcome, and the reason.
Which Permit.io component enforces each layer
One agent action crosses several layers. Each layer asks its own question of the same identity and the same policy.
| Layer | Permit component | The question it asks |
|---|---|---|
| Endpoint and process | Coding Agents Gateway | May this agent process reach this destination with this payload? |
| Tools (MCP and SaaS) | Permit MCP Gateway | May this agent call this tool, with these arguments, for this human? |
| Outbound APIs | HTTP Egress Proxy | May this agent's workflow reach this host, path, and method? |
| Applications and internal APIs | Permit PDP with permit.check() | May this agent merge, deploy, or approve here? |
| Data | Permit PDP in front of your data layer | May this query read this row or column? |
All of them share the same identities, the same policy in your Permit.io environment, and the same audit trail. See the reference architecture for how a single factory run moves through them.
Feature availability
All the components in this section are generally available.
| Capability | Where it lives | Plan |
|---|---|---|
| Gateway authentication, per-tool authorization, consent, audit log | Permit MCP Gateway | Free plan and up |
| Deny-by-default egress, API workflows, vaulted credentials | HTTP Egress Proxy | Available on request (email support to turn it on) |
| Human-in-the-loop approvals, trusted agent bypass | Permit MCP Gateway | Enterprise |
| Agent interrogation and intent drift detection | Permit MCP Gateway | Talk to us |
| Endpoint and process-level enforcement | Coding Agents Gateway | Talk to us |
| Customer-controlled and fully on-premises deployment | All gateways | Enterprise |
For the full list of gateway features and plans, see Advanced features.
Start here
- Reference architecture: the identity model, the five enforcement layers, and deployment options.
- Roll out a governed pilot: route one team's agents through Permit and tune on real traffic.
- Policy patterns: trust levels per workflow, approval checkpoints, separation of duties, and checks in your own services.
- Audit and compliance evidence: what the decision log records and how it maps to common audit questions.
Frequently asked questions
Do native agent settings secure a software factory?
They help, and you should keep them. Claude Code managed settings, Cursor enterprise controls, Codex managed configuration, and the GitHub Copilot coding agent firewall each govern one tool. A factory runs several tools, and its agents reach MCP servers, APIs, applications, and data that those settings don't cover. Permit adds one identity model, one policy, and one decision log across all of them.
Can a coding agent approve or merge its own pull request?
It should not. With a distinct identity per agent, policy can deny the authoring agent the merge or approve action on its own change and route that step to a human. See separation of duties.
Will approvals slow the factory down?
Not if they sit only at checkpoints that are hard to undo. Low-risk work runs on trust levels and allowlists, approvals time out to a rejection, and named CI agents can bypass approval on a server. See Human-in-the-loop approvals.
Can the factory run air-gapped?
Yes. Permit MCP Gateway runs hosted, customer-controlled, or fully on-premises with no internet connection required. See Enterprise deployment.