Loading
Permit Agent Security
Your agents write, test, and ship code while humans approve at checkpoints. Give every agent its own identity delegated from a human, deny by default, check every call against policy outside the model, stop risky steps for a person, and keep one decision log as the factory's audit trail.
Endpoint · MCP tools · APIs · Apps · Data · One policy
Or start free with Permit MCP Gateway at agent.security →gateway · live decisions
Enforcingcopilot-agent $ GET internal-api.acme.dev/schemas
policy · scoped grant via delegation
claude-code $ read ~/.aws/credentials
policy · default-deny, no matching grant
codex $ POST paste-bin.cc/x91f · payload: env vars
guardian · exfiltration pattern detected
cursor $ POST registry.npmjs.org /publish
policy · high-risk path → human approval
claude-code $ GET api.github.com/repos/acme/api
policy · destination on allowlist
Interrogation asks · Guardians watch · Policy decides
A software factory is a setup where fleets of AI coding agents pick up tickets, write code and tests, review, and open pull requests, with humans approving at checkpoints such as merge and deploy. Agents run in IDEs, CLIs, CI pipelines, and cloud background jobs, often many loops in parallel.
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.
Vendor-neutral by design. The controls sit at the process, tool, API, app, and data layers, not inside any one agent's settings file.
The factory got faster. The security model underneath it is still the one from when agents were autocomplete: they run as the developer, with the developer's tokens, and nothing in between asks whether a given action should happen.
They inherit SSH keys, cloud CLI profiles, GitHub tokens, and .env files. Nothing scopes that access to the ticket in hand.
CI and background agents get a long-lived, broad token because it is the fastest way to make them work. It never narrows and rarely expires.
Issues, PR descriptions, READMEs, changelogs, and MCP tool responses become instructions the moment an agent reads them.
The agent holds real authority and can be talked into using it for someone who has none. Authentication cannot help: the agent is who it says it is.
The logs say the developer did it. You cannot tell which agent acted, who delegated the task, or what the agent said it was trying to do.
If one connected agent or MCP server is malicious, it touches every build the factory ships. Agents nobody registered are the hardest part.
The same access control discipline you already apply to people, applied to every agent and every call it makes. Guardrails in a prompt are suggestions. Policy outside the model is a guarantee.
Each agent identity binds the human who delegated the work, the client the agent runs as, the workflow, and its declared intent. Revoke the human and every agent acting for them loses access on its next call.
Agents start with nothing. Destinations, tools, and paths are allowed per workflow, not per developer. A dependency-bump agent has no reason to read ~/.aws/credentials or post to a paste site.
Every outbound call, MCP tool call, and protected API call asks one question: may this agent, acting for this human, in this workflow, do this action on this resource right now? Intent drift can downgrade trust, ask for consent again, or block.
Approval on merge to protected branches, production deploys, secrets, production data, and package publishing. Notifications by email or Slack, rejection on timeout, and a bypass for named CI agents so approvals stay meaningful.
Every allow and deny with the human, the agent, the tool or destination, the time, and the reason. API first, so it lands in the SIEM and logging pipeline you already run. That log is the factory’s audit trail.
Agents never approve or merge their own changes.
With a distinct identity per agent, separation of duties becomes a policy rule instead of a team convention: the identity that wrote the change cannot be the one that approves it.
A prompt injection that slips past one check should meet the next. Each layer an agent action crosses asks its own question of the same identity and the same policy.
One software factory, five enforcement points, one policy
Each agent: its own identity, bound to the human, the workflow, and its declared intent.
Endpoint and process layer
A user-space proxy scoped to coding agent processes, pushed through the MDM tooling you already run. Default deny with an explicit allowlist, intent interrogated per call, and the final decision left to deterministic policy. Generally available.
Learn more →Tool layer
Authenticates the human through your IdP, classifies each tool by risk, checks every tool call with deny by default, shows a consent screen, keeps upstream credentials vaulted so agents never hold them, and logs every call.
Learn more →API, app, and data layers
RBAC, ABAC, and ReBAC for the apps, APIs, and data your agents touch, with the policy decision point running next to your workloads. The agent is just another subject: permit.check("agent|ci-fixer", "merge", "repo:payments-api").
Learn more →Claude Code managed settings, Cursor enterprise controls, Codex managed configuration, and the Copilot coding agent firewall are worth turning on. They govern one tool each. A factory runs many tools, and its agents reach systems those settings never see.
| Capability | Native agent settings | Permit Software Factory Security |
|---|---|---|
| Allow and deny rules for commands, files, and tools | Yes, per tool, in each vendor’s own format | One policy for every agent, kept outside the agent’s config |
| Sandboxing and isolation | Yes, varies by tool | Keep it. Permit decides what the agent’s credentials may do |
| Identity per agent, delegated from a human | Varies; agents often run as the developer | Human, client, workflow, and intent bound into one identity |
| Enforcement beyond the agent process | Limited to what the tool itself controls | Endpoint, MCP tools, APIs, applications, and data |
| Human approval at risky steps | Mostly prompts to the developer running the agent | Routed to approvers in the dashboard or Slack, with timeouts that reject |
| Audit trail | Per vendor, per tool | One decision log across every agent, exportable to your SIEM |
Platform and engineering leaders who are standing up agent factories do not start with a threat model. They start with friction, accountability, and what happens when something gets blocked. These are the questions we hear, and how the model answers them.
"We want every agent to have an identity and a permission set, and to know what it did."
"When an agent gets denied, how does a human escalate or override?"
"I don’t want every product manager to OAuth into every MCP server."
"Can we block the session instead of the agent, and skip the re-auth?"
"Can the audit log go into our observability stack?"
"How do I know nobody connected an agent that injects malware into every build?"
The path we recommend when teams ask where to start. It gets you to a governed pilot quickly without making approvals the bottleneck.
List the user stories the factory runs, such as "fix a failing test" or "bump a dependency and open a PR". Turn each into the tools and destinations it needs, who delegates it, and its trust level.
Production deploys, secrets, sensitive data, and third-party systems. Add a check in the gateway, another in the application, and another in front of the data.
Route one team through the gateways. Watch human access and factory runs side by side. Count blocks, approvals, rejections, and intent drift.
Most early blocks are allowlist gaps. Some are not, and those are why you did this. Adjust trust levels until normal work stops noticing the controls.
More teams, more workflows, more end-to-end coverage, with the same identities and the same policy.
When code is written by agents, the old questions get harder: who made this change, who approved it, and was access least privilege? Each control produces a record that answers one of them.
| Audit question | Control in the factory | Where it shows up |
|---|---|---|
| Who made this change? | A distinct identity per agent, linked to the human who delegated the task | Decision log: human, agent, action, resource |
| Who approved it? | Human approval on merge, deploy, secrets, and production data; agents cannot approve their own changes | Approval history with approver, outcome, and time |
| Was access least privilege? | Deny by default, allowlists per workflow, trust ceilings set by admins | Policy as code in Git, with reviewable changes |
| Can you revoke access fast? | Revoking a human cascades to every agent acting for them | Revocation events in the audit log |
| Can you detect misuse? | Intent declared and checked; drift triggers re-consent or a block | Denials and drift events, exported to your SIEM |
| Where are the secrets? | Upstream credentials vaulted in the gateway; agents receive scoped access, not keys | Gateway configuration and credential inventory |
The same records are what reviewers look for under change management (SOC 2 CC8.1, ISO/IEC 27001 Annex A 8.32) and logical access (SOC 2 CC6), and they address the identity and tool misuse risks in the OWASP Top 10 for Agentic Applications (ASI02 and ASI03). See the compliance mapping.
Permit provides the controls and the records. Your auditor decides how they apply to your scope. Permit.io holds a SOC 2 Type II attestation; see the trust center.
Start hosted at agent.security. Keep the gateway and a local PDP in your network while Permit hosts the control plane. Or run the whole stack on-premises with no internet connection, which fits an air-gapped factory. Customer-controlled and on-premises deployments are on Enterprise plans.
A factory attracts agents nobody registered: a side experiment, a CLI installed last week, an MCP server added with a one-line JSON edit. Endpoint enforcement scoped to agent processes narrows that gap. Track the agents, not the humans, and inventory them before you write your first policy.
A software factory is an engineering setup where fleets of AI coding agents (Claude Code, Cursor, Codex, CI and background agents) pick up tickets, write code, write tests, review, and open pull requests, while humans approve at a few checkpoints such as merge and deploy. The output is real code shipped to real customers.
Software factory security is the practice of governing the AI coding agents that write, test, and ship code. Each agent gets its own identity delegated from a human, actions are denied by default, every call is checked against policy outside the model, humans approve risky steps, and every decision is logged as the audit trail.
No. In defense and government, "software factory" names a DevSecOps platform of pipelines, tooling, and accredited environments, such as Kessel Run or Platform One. Here the term means a factory staffed by AI coding agents. The controls still matter for those platforms once agents start committing code inside them.
Agents run with the developer's credentials or long-lived service tokens while reading untrusted content such as issues, READMEs, dependency changelogs, and MCP tool responses. A prompt injection in any of them can turn that access into data exfiltration or a destructive change, and without per-agent identity nobody can tell which agent did it.
They help, and you should keep them. Sandboxes limit where code runs, and vendor settings in Claude Code or Cursor set per-tool rules. Neither decides which credentials, tools, destinations, and data a given agent may use for a given task, across every agent vendor, with one audit trail. That decision needs identity and a per-call policy check.
Each agent gets a composite identity: the human who delegated the work, the client the agent runs as (for MCP, the OAuth client ID it registers with), the workflow it executes, and the intent it declared. The grant is a relationship from human to agent to action to resource, so revoking the human revokes every agent acting for them.
Put approval on actions that are hard to undo: merging to protected branches, production deploys, secrets, production data, and package publishing. Everything else runs on trust levels and allowlists. Approvals can notify by email or Slack, reject on timeout, and let named CI agents bypass approval, so normal work does not stop.
It should not. Separation of duties says the identity that writes a change is not the identity that approves it. With per-agent identity, policy can deny an agent the merge or approve action on a change it authored and route that step to a human reviewer, and the decision log shows who approved what.
Auditors ask who changed what, who approved it, and whether access was least privilege. Per-agent identity, deny-by-default policy, human approval at change checkpoints, and a decision log with the human, agent, action, resource, and reason produce that evidence. Permit provides the controls and the records; your auditor decides how they map to your scope.
No. Keep them. Native settings, permission rules, sandboxes, and approval modes are configured per tool. Permit adds one identity model, one policy, and one decision log across every agent vendor, and enforces them at the MCP, API, application, and data layers that a single agent's settings do not reach.
For each action: the delegating human, the agent identity, the tool or API called, the target resource, the policy decision (allow, deny, or approval), any human approver, the reason, and a timestamp. That lets an auditor attribute each change to an agent and to an accountable person.
Combine signals: endpoint visibility into agent CLIs, IDE extensions, and local MCP servers; identity provider and SaaS logs for agent sign-ins and OAuth grants; and repository and CI logs for agent-authored commits. Register each agent with an owner and a scope, then route it through policy. Agents outside your controls are the gap to close first.
Yes. Permit MCP Gateway runs hosted, customer-controlled (the gateway and a local PDP in your network, with Permit hosting the control plane), or fully on-premises with no internet connection required. Customer-controlled and fully on-premises deployments are on Enterprise plans.
Map the workflows your factory runs, mark the sensitive boundaries (production, secrets, sensitive data), and pilot with one team. Count blocks, approvals, and intent drift, tune trust levels until normal work stops noticing the controls, then expand to more teams with the same identities and policy.
Go deeper: the software factory security blueprint, the docs, trust levels for coding agents, and Permit for security teams.
Let agents do the work. Keep identity, policy, and approval where they belong: outside the model.
Or start free with Permit MCP Gateway at agent.security →