How do teams decide whether runtime security should sit with AppSec or identity?

Teams should stop treating that as an either-or choice. Runtime security sits at the point where application behaviour and identity use intersect, so ownership has to be shared across AppSec, cloud security, and identity governance. If a flaw can be reached by a credential, token, or workload identity, it is both an application and identity problem.

Why This Matters for Security Teams

runtime security is where an application’s live behaviour, its secrets, and its identity assertions meet. That makes the ownership question less about organisational charts and more about control points. AppSec tends to focus on code, dependency risk, and exploitability, while identity teams focus on authentication, authorisation, and lifecycle. At runtime, a flaw can be reached through either path, especially when tokens, API keys, or workload identities are involved.

The practical risk is that teams split responsibility and assume the other group is watching. NHIMG research on 52 NHI Breaches Analysis shows how often weak identity controls and exposed credentials become the entry point for broader compromise. That is why runtime security cannot be reduced to code scanning alone or to IAM reviews alone. The operating model has to reflect live enforcement, not just static design.

Current guidance from NIST Cybersecurity Framework 2.0 supports shared accountability across identify, protect, detect, and respond functions. In practice, many security teams encounter ownership gaps only after a leaked token or over-privileged workload identity has already been used in production.

How It Works in Practice

The cleanest operating model is to assign runtime security by control plane, not by team label. AppSec owns application behaviour, secure design patterns, code-level guardrails, and runtime abuse cases. Identity governance owns credential issuance, privilege scope, token lifecycle, and detection of anomalous identity use. Cloud security often sits in the middle, enforcing policies at the platform boundary and feeding telemetry back to both.

For non-human identities, that split becomes more important because a service account, token, or agent identity can be created, chained, and abused faster than a manual review process can react. NHIMG’s Ultimate Guide to NHIs frames the core issue clearly: the identity itself is often the runtime attack surface. Teams should therefore align on three practical questions:

• Who approves the identity or token that can reach production?
• Who defines and tests the runtime policy that constrains what it may do?
• Who owns revocation, alerting, and forensic evidence when behaviour changes?

At the implementation layer, current best practice is to combine workload identity, short-lived credentials, and policy-as-code. That means using cryptographic proof of workload identity where possible, issuing secrets just in time, and evaluating access at request time rather than relying on static RBAC alone. This is especially important when an application can call downstream services, fetch secrets, or invoke automation on its own. OWASP’s LLM application guidance and NIST’s AI risk guidance both point toward runtime controls that observe actual behaviour, not assumed intent.

These controls tend to break down when legacy applications share broad service accounts across multiple environments because ownership becomes unclear and revocation risk spreads across unrelated systems.

Common Variations and Edge Cases

Tighter runtime control often increases operational overhead, so organisations have to balance containment against deployment speed and incident response load. That tradeoff becomes visible in mixed estates where some workloads are human-driven web apps, some are APIs, and others are autonomous agents or scheduled jobs.

There is no universal standard for this yet, but current guidance suggests a few patterns. High-change product teams usually keep AppSec accountable for runtime abuse cases, while identity engineers own the policy that governs tokens, service principals, and workload credentials. Platform teams then enforce guardrails through the infrastructure layer. For autonomous systems, the boundary shifts further toward identity governance because an agent may chain actions, request new privileges, or use tool access in ways developers did not predefine.

That is why the question is not “who owns runtime security” but “who owns the failure mode.” If the likely break is exploit code, AppSec leads. If the likely break is credential misuse, token replay, or privilege escalation, identity leads. In many production environments, both are accountable because attack paths now cross application logic and identity posture. NHIMG’s Top 10 NHI Issues is a useful reminder that credential sprawl, poor rotation, and over-privilege rarely stay isolated to one team’s domain.

Where this guidance gets messy is in SaaS integrations and third-party OAuth apps, because ownership often sits with the business owner while the technical blast radius sits elsewhere. That is where policy clarity matters more than team preference.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• How do teams decide whether IBAC should sit alongside IAM or replace it?
• How should security teams decide whether an AI agent gets human or non-human identity?
• How do identity teams decide whether runtime detection or posture management should come first?