Why do agentic software factories increase identity risk?

Why This Matters for Security Teams

Agentic software factories increase identity risk because they turn identities into live execution channels, not just login records. Each agent, workflow, and tool call may need its own credential, policy decision, and audit trail, which multiplies the number of places where misuse can occur. Static IAM assumptions become brittle when systems can plan, retry, chain tools, and act faster than human reviewers can intervene.

This is why NHI Management Group treats agentic identity as an operational control problem, not a theoretical one. The OWASP NHI Top 10 and NIST AI Risk Management Framework both point toward the same reality: autonomous systems need tighter identity scoping, stronger runtime controls, and clearer accountability than human-centric workflows. NHIMG’s AI Agents: The New Attack Surface report found that 80% of organisations report agents already performed actions beyond intended scope, including revealing access credentials in 23% of cases. In practice, many security teams encounter agent identity abuse only after the workflow has already overreached, not during design review.

How It Works in Practice

In an agentic software factory, identity is not a single account. It is a mesh of workload identities, ephemeral secrets, delegated permissions, and tool-scoped authorisations that may exist only for the duration of one build, test, or deployment task. That is a major shift from human IAM, where a person can be reviewed against a role and a relatively stable set of entitlements.

For autonomous systems, current guidance suggests moving toward context-aware authorisation at request time. The agent proves what it is through workload identity, then receives only the minimum access needed for the next action, ideally through just-in-time, short-lived credentials. That means short TTLs, automatic revocation after task completion, and policy checks that consider the agent’s intent, the target system, the sensitivity of the data, and the current risk posture. Standards and research from CSA MAESTRO agentic AI threat modeling framework and OWASP Agentic AI Top 10 both reinforce this direction.

Practically, teams should separate human approvals from machine execution. A developer may request a release, but the agent that builds, scans, signs, and deploys should authenticate with its own workload identity and receive a narrowly scoped token for each step. Secrets should be dynamic, not baked into pipelines, and policy should be evaluated in real time using policy-as-code rather than static RBAC alone. NHIMG’s Ultimate Guide to NHIs and OWASP Agentic Applications Top 10 both emphasise that the control point must follow the workload, not the organizational chart. These controls tend to break down in high-churn CI/CD environments with shared runners and long-lived service tokens because one compromised credential can be reused across many autonomous tasks.

Common Variations and Edge Cases

Tighter identity control often increases deployment friction, requiring organisations to balance developer velocity against revocation speed and auditability. That tradeoff becomes more visible in software factories that rely on reusable templates, ephemeral build agents, or multi-agent orchestration across cloud and on-prem systems.

Best practice is evolving, but there is no universal standard for this yet. Some environments can adopt SPIFFE-style workload identities and short-lived OIDC tokens cleanly, while others still depend on secret stores, legacy CI systems, or vendor-managed agent frameworks that do not expose enough runtime context for fine-grained decisions. In those cases, the safer pattern is to segment agents by function, reduce standing privilege, and force each agent to re-authenticate for each sensitive tool invocation rather than inheriting broad access for the whole pipeline.

One important edge case is when agents can create or spawn other agents. That multiplies identity sprawl and makes ownership harder to track, especially when logs only show the parent workflow, not the delegated child action. NHIMG’s 52 NHI Breaches Analysis shows how often weak credential hygiene and poor lifecycle controls become the real failure point. The same issue appears in NIST Cybersecurity Framework 2.0 and the MITRE ATLAS adversarial AI threat matrix: when autonomous workflows can chain actions faster than governance can observe them, identity risk shifts from access misuse to control-plane loss.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents increase non-human identity risk?
• Why do AI agents create new risk in non-human identity management?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?