Software Factory Security: How to Secure a Fleet of AI Coding Agents

TL;DR: A software factory is a fleet of coding agents (Claude Code, Cursor, Codex, cloud and background agents) that write, test and ship code while humans approve at checkpoints. Securing it means giving every agent its own identity delegated from a human and scoped to the task, denying by default, checking every tool call against policy outside the model, putting a human approval on merge, deploy, secrets and production data, and keeping one decision log as the factory's audit trail. Enforce that same policy at the endpoint, at the tool layer, and in your apps, APIs and data.

"Software factory" used to mean CI pipelines and golden paths. For platform and security teams in 2026, software factory security means governing fleets of AI coding agents. A ticket lands, an agent picks it up, a second agent writes tests, a third reviews, and a human clicks merge. Teams increasingly run many of these loops in parallel. The output is real code in real repos, deployed to real customers.

The security model under most of these factories hasn't changed since the agents were autocomplete. They run as the developer, with the developer's tokens, and nothing in between asks whether a given action should happen. That gap is what this post is about, and it closes with a checklist and an adoption path a platform or security lead can start on this quarter.

What goes wrong in a software factory

Every coding agent in the factory is a privileged process. It holds shell access, credentials and outbound network reach, and it acts at machine speed. Five problems show up again and again.

1. Agents borrow human credentials. The agent runs inside the developer's session, so it inherits their SSH keys, cloud CLI profiles, GitHub tokens and .env files. Nothing scopes those to the ticket the agent is working on.
2. Standing god keys. Background and CI agents usually get a long-lived token with broad scopes because it is the fastest way to make them work. That token never expires and never narrows.
3. Prompt injection rides in on normal work. Issues, PR descriptions, READMEs, dependency changelogs and MCP tool responses all become instructions once an agent reads them. A poisoned ticket is enough. We walked through one in a poisoned Linear ticket told our AI agent to leak the team.
4. The agent is a confused deputy. It holds real authority and can be talked into using it for someone who has none. Authentication can't help, because the agent really is who it says it is. See the confused deputy problem in AI agents and MCP.
5. No attribution. When something goes wrong, the logs say "the developer did it." You can't tell which agent acted, which human delegated the task, or what the agent claimed it was trying to do.

Sandboxes help with the blast radius of code execution, but they don't decide what an agent is allowed to do with the credentials it holds. We covered that gap in coding agent sandboxes don't solve credential authorization.

The security model: five controls

The fix is the same access control discipline we already apply to people, applied per agent, per call.

1. Each agent gets its own identity, delegated from a human

An agent identity in a factory is composite. It binds the human who delegated the work, the client the agent runs as, the workflow it is executing, and the intent it declared. A grant is a relationship: human to agent to action to resource. When you revoke the human or change their role, every agent acting for them loses that access on its next call, with no token hunt.

This is how Permit MCP Gateway models it. As shared in our docs, an agent is identified by the OAuth client ID it registers with, and revoking a human's access cascades to all of their agents for that server. For the longer argument on why service accounts don't fit, read agent identity vs service accounts.

2. Deny by default

Start every agent with nothing. Allow known destinations, tools and paths explicitly. This is firewall logic applied to a new class of process, and it is the only baseline that holds up when the agent is manipulated. A factory agent assigned a dependency bump has no reason to read ~/.aws/credentials or post to a paste site.

3. A runtime policy check on every call, outside the model

Guardrails in the prompt are suggestions. The decision has to come from a policy engine the model can't talk to. Every outbound call from the agent process, every MCP tool call and every protected API call gets a check: may this agent, acting for this human, in this workflow, do this action on this resource right now?

Intent belongs in that check. Ask the agent what it is trying to do, then compare later calls with that declaration. When behavior drifts from the stated intent, policy can downgrade trust, ask for consent again or block. We went deeper on this in agentic intent and AI agent drift.

4. Human approval at the risky checkpoints

The factory works because humans stay at a few checkpoints and stay out of everything else. Put approvals on:

• merging to protected branches
• deploying to production
• reading or rotating secrets
• touching production data
• publishing packages or calling a destination for the first time

Approval has to be configurable or it turns into rubber stamping. In Permit MCP Gateway, as shared in our docs, human-in-the-loop approvals can trigger on a trust level threshold or on specific tools, hold the call as pending until an admin decides, notify admins by email or Slack, reject on timeout, and let named agents such as CI bots or scheduled pipelines bypass approval. That's how factory runs avoid drowning in approval prompts while the dangerous paths still stop for a person. Human-in-the-loop approvals are on Enterprise plans.

5. A decision log that is the factory's audit trail

Every allow and deny gets recorded with the human, the agent, the tool or destination, the time and the reason. That record answers the questions auditors and incident responders will ask: who delegated this, what did the agent try, and why was it allowed. Make it API first so it lands in the SIEM and observability stack you already run. See the human to agent delegation audit trail for the fields that matter.

Defense in depth: one policy across every layer

A prompt injection that slips past one check should still meet the next. In a factory, an agent action crosses several layers, and each one should ask its own question of the same identity and the same policy.

Permit maps onto this as one chain of control:

• Permit Coding Agents Gateway covers the endpoint and process layer. The Coding Agents Gateway is generally available. It is a process-level, user space proxy scoped to coding agent processes such as Claude Code, Cursor and Codex, pushed to managed machines through the MDM and software distribution tooling you already run. It starts from default deny with an explicit allowlist, interrogates the intent behind each call, keeps watching the session after access is granted, and leaves the final decision to deterministic policy, including human-in-the-loop on dangerous paths. Agent identities are governed through your IGA and decisions are audited to your SIEM.
• Permit MCP Gateway covers the tool layer. It authenticates the human through your IdP, classifies each tool by risk, checks every tool call against policy with deny by default, shows a consent screen, keeps upstream credentials vaulted so agents never hold them, and logs every allowed or denied call. MCP Gateway Free includes 10 tenants, 1 environment, 7 days of audit log retention and 1,000 monthly active users.
• The Permit platform covers app, API and data authorization with RBAC, ABAC and ReBAC, on a hybrid architecture where the policy decision point runs close to your workloads.

All three share the same identities, policies and audit chain. The MCP side of this connects to standards work too: MCP Enterprise-Managed Authorization explains how enterprise IdPs issue access to MCP servers, and OAuth on MCP covers the client registration flows underneath.

A reference architecture you can act on

Here is the checklist we'd hand a platform or security lead running a software factory.

Identity

• Every agent has its own identity, separate from the developer's
• Every agent identity links to the human who delegated the work
• No long-lived, broad tokens in agent environments; upstream credentials stay in a gateway
• Offboarding a human revokes all of their agents in one step

Policy

• Default deny for agent egress, tools and data
• Allowlists per workflow, not per developer
• Trust levels per tool and per path, with low risk paths running without friction
• Intent declared and checked, with drift triggering re-consent or a block
• Policy lives outside the model and outside the agent's own config

Checkpoints

• Human approval on merge, deploy, secrets, production data and package publishing
• Agents never approve or merge their own changes
• Approval timeouts reject instead of allowing

Evidence

• Every decision logged with human, agent, action, resource, outcome and reason
• Logs leave the agent's reach and land in your SIEM
• Counts of denies, approvals, rejections and drift reviewed weekly

An illustrative policy

The snippet below is an example written for this post, not a shipped policy. It shows the shape of the rule: deny by default, allow scoped actions inside the agent's workflow, and route risky actions to a human.

# Illustrative example only.
package factory.agents

default decision := "deny"

risky_actions := {"merge_protected", "deploy_prod", "read_secret", "query_prod_data", "publish_package"}

# Scoped work inside the delegated workflow runs without a prompt
decision := "allow" if {
    input.agent.delegated_by == input.human.id
    input.action in data.workflows[input.agent.workflow].allowed_actions
    not input.action in risky_actions
    input.agent.intent_matches
}

# Risky checkpoints always go to a human
decision := "require_approval" if {
    input.agent.delegated_by == input.human.id
    input.action in risky_actions
    input.agent.intent_matches
}

If you already use Permit in code, the same question is a single check with the agent as the subject, for example permit.check("agent|ci-fixer", "merge", "repo:payments-api"), with the delegating human and the workflow modeled as relationships.

How to roll out agent security in your software factory

This is the path I recommend when teams ask where to start. It gets you to a controlled pilot quickly without making approvals the bottleneck.

1. Map the factory's workflows. Write down the user stories the factory runs, such as "agent fixes a failing test" or "agent bumps a dependency and opens a PR." Turn each into the MCP tools and destinations it needs, and decide who delegates it and what trust level it gets.
2. Mark the sensitive boundaries. Production deploys, sensitive data sources and third-party systems. Add defense in depth there: a policy check in the gateway, another in the application, and another in front of the databases the agents reach.
3. Pilot with one team. Run the gateway for one team or department. Watch the usage from both human access and factory runs. Count blocks, rejections and intent drifts.
4. Tune on what you see. Most early blocks are allowlist gaps. Some aren't, and those are the reason you did this. Adjust trust levels and approvals so normal work stops noticing the controls.
5. Expand. Move to more end-to-end coverage, more use cases and more teams, with the same identities and policy.

On deployment: as shared in our docs, Permit MCP Gateway runs hosted, customer-controlled or fully on-premises. Customer-controlled keeps the gateway and a local PDP in your network while Permit hosts the control plane. Fully on-premises runs the whole stack in your environment with no internet connection required, which fits an air-gapped "dark factory." Both are on Enterprise plans. The hosted gateway is the quickest way to start, at agent.security.

The open problem: agents you can't see

Everything above governs agents that route through your controls. A software factory also attracts agents nobody registered: a developer's side experiment, a new CLI someone installed last week, an MCP server added with a one line JSON edit. You can't govern agents you can't see. Endpoint enforcement scoped to agent processes narrows that gap, and the industry still has work to do here. If you run a factory, inventory your agents before you write your first policy.

For the security team's view of all this, start at Permit for security teams. For how trust levels map to commands and tools, read trust levels for coding agents.

FAQ

What is a software factory?

A software factory is a setup where fleets of AI coding agents write, test and ship code, with humans approving at checkpoints such as merge and deploy. Agents run in IDEs, CLIs, CI and cloud background jobs.

What is the biggest AI coding agent security risk?

Agents run with broad human or standing credentials while reading untrusted content. A prompt injection in an issue or README can turn that access into data exfiltration or a destructive change, and without per-agent identity nobody can tell which agent did it.

Do sandboxes secure coding agents?

Sandboxes limit where code runs. They don't decide which credentials, tools and destinations an agent may use for a given task. You need identity and a per-call policy check on top.

Where should human approval go in a software factory?

On actions that are hard to undo: merging to protected branches, production deploys, secret access, production data and package publishing. Everything else should run on trust levels and allowlists so approvals stay meaningful.

How do I audit what autonomous coding agents did?

Log every policy decision with the human, the agent, the action, the resource, the outcome and the reason, and send it outside the agent's reach to your SIEM. That log is the factory's audit trail.