Because the workflow is no longer isolated behind a fixed embedded surface. Once identity logic lives in repository-owned code, teams must govern code provenance, policy drift, and approval boundaries across development, security, and release management.
Why This Matters for Security Teams
App-native identity workflows shift IAM from a central control plane into the software delivery path. That creates governance risk because the access decision is now shaped by code changes, dependency updates, and release velocity, not only by policy design. Security teams must track who can alter identity logic, how approvals are enforced, and whether secrets and tokens are introduced or changed outside normal IAM review. Current guidance suggests treating these workflows as both identity and software supply-chain problems, consistent with NIST Cybersecurity Framework 2.0.
The practical issue is that repository-owned identity code can drift faster than governance can see it. A developer may add a token path, broaden a service account scope, or bypass a control to unblock deployment, and the change may look legitimate in code review while silently weakening identity assurance. NHIMG research shows the scale of the problem: 30.9% of organisations store long-term credentials directly in code, and 96% store secrets outside secrets managers in vulnerable locations such as code, config files, and CI/CD tools, as covered in the Ultimate Guide to NHIs. In practice, many security teams encounter identity drift only after a release has already expanded privilege.
How It Works in Practice
App-native identity workflows usually embed one or more of four patterns: secrets in application code, workflow-specific service accounts, pipeline-issued tokens, and policy checks implemented in application logic. The governance risk comes from the fact that each pattern creates a new approval boundary. IAM may still own the global policy, but repository owners control the implementation details that determine whether the policy is actually enforced.
A stronger operating model separates the identity primitive from the application logic. For autonomous or semi-autonomous workloads, that means using workload identity, short-lived credentials, and policy-as-code rather than static secrets and hard-coded entitlements. Where possible, teams should prefer JIT issuance, tight TTLs, and explicit revocation paths so a credential exists only for the task that needs it. Runtime authorisation should evaluate context, intent, and environment, not just a preassigned role. That is the direction reflected in Top 10 NHI Issues and in the broader lifecycle controls discussed in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
- Define who can create or modify identity code, and make that separate from who approves production access.
- Issue credentials just in time, tie them to workload identity, and expire them automatically after the task completes.
- Store secrets in managed systems, not in repositories, build scripts, or deployment manifests.
- Review policy changes like security changes, because policy drift is often the real failure point.
- Log the full chain from code commit to token issuance to production use so audit teams can reconstruct intent.
This model aligns with the control intent in NIST Cybersecurity Framework 2.0, but it tends to break down in fast-moving release pipelines where identity logic is generated by templates, copied across services, or overridden to meet deployment deadlines because governance loses line-of-sight between approval and execution.
Common Variations and Edge Cases
Tighter identity governance often increases deployment friction, so organisations have to balance velocity against control assurance. That tradeoff is especially visible in environments with multiple microservices, frequent blue-green releases, or autonomous agents that call tools on their own schedule.
There is no universal standard for this yet, but current guidance suggests treating the most dynamic workloads differently from stable human-facing apps. For example, ephemeral build jobs may justify highly scoped, short-lived access, while long-running services need stronger rotation and offboarding controls. Multi-tenant platforms and shared CI/CD runners also complicate accountability because one workflow may mint credentials for many downstream systems. In those cases, RBAC alone is usually too coarse, and intent-based or context-aware authorisation becomes more useful. That is why NHIMG analysis in the 52 NHI Breaches Analysis remains relevant: the issue is not only whether access exists, but whether it can be traced, justified, and revoked at the right moment.
For governance teams, the key edge case is when the identity workflow itself becomes code owned outside IAM. In those environments, security should also align to NIST Cybersecurity Framework 2.0 and recognise emerging agent guidance such as OWASP NHI Top 10, because the governance problem is no longer just entitlement management. It is control of autonomous, code-driven access pathways that can change faster than policy review cycles.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers risky secrets and credential handling in app code. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access enforcement and least privilege for workflows. |
| NIST AI RMF | Helps govern dynamic, code-driven identity decisions and accountability. |
Assign ownership for runtime identity decisions and monitor them for drift, misuse, and unintended escalation.
