Should AI red teaming be governed like application security or like identity control?

Why AI Red Teaming Needs Both AppSec and Identity Governance

ai red teaming sits at the intersection of what the system is allowed to do and what it is able to reach. If a test only checks model behavior, it can miss unsafe execution paths, overbroad permissions, and tool access that turn a harmless prompt into a real incident. If it only checks identity, it can miss prompt-driven abuse that exposes application weaknesses.

For practitioners, the core question is not whether the exercise is “appsec” or “identity,” but whether the red-team scenario can create material impact through either channel. That makes the governance model hybrid by design: the red team should be allowed to probe application boundaries, but the control owner must also understand delegated authority, credential scope, and what the agent can touch once it is invoked.

That is why a red-team finding against an AI system is often only actionable when it is translated into both exploitability and authority. The first tells you whether the behavior is dangerous; the second tells you whether the behavior can actually be used to cause loss, movement, disclosure, or unauthorized execution.

Where Application Security Ends and Identity Control Begins

Application security governs exposure, validation, unsafe inputs, broken authorization, and whether the system enforces the rules it claims to enforce. In AI red teaming, that includes prompt injection resistance, unsafe tool invocation, resource abuse, and whether the application leaks data or executes unintended actions when probed. A useful baseline for testing those controls is the OWASP ASVS, because it anchors the discussion in authentication, session, and access control requirements rather than in model output quality alone.

Identity control governs who or what can act, what the delegated authority is, and whether the access path is appropriately bounded. That matters in AI systems because the risky outcome is often not the answer text itself, but the fact that the system can invoke tools, reach data, or execute operations on behalf of a user, service, or agent. In other words, red teaming should ask not only “can the model be manipulated?” but also “what identity context makes the manipulation consequential?”

That distinction is especially important when the red team finds a path from a benign interaction to privileged behavior. The application weakness may be the trigger, but the identity model determines the blast radius, because overbroad delegation, reusable credentials, and weak separation of duties make the same flaw much more damaging.

How to Govern AI Red Team Results Without Splitting the Program

The best governance model treats AI red teaming as one program with two lenses. The test plan should include application-security scenarios, such as injection, data exposure, and authorization bypass, and identity scenarios, such as impersonation, delegated access abuse, and privilege escalation through tools or connectors. For agentic systems, Red Teaming AI Agents for Identity Abuse is a useful internal reference because it ties those findings back to authority, credential misuse, and delegation abuse.

A second useful anchor is the OWASP Agentic Applications Top 10, which helps structure findings around tool misuse, identity and privilege abuse, and agent orchestration risk. That kind of framing prevents teams from treating every red-team issue as either a generic app bug or a pure identity defect when, in practice, many findings span both.

The operating rule is simple: classify the failure by the control that would have prevented the harmful outcome. If stronger input handling would have stopped it, appsec owns the remediation. If tighter scopes, delegated authority, or credential design would have contained it, identity owns the remediation. Many findings will require both teams, but one governance model should coordinate them so the same exposure is not assessed twice in isolation.

Practitioner Guidance

What to verify: Every red-team scenario should record the exact authority in play, including user context, service context, and any tool or connector permissions. If the test cannot state what the system was allowed to do, the finding is incomplete.

Decision rule: If the failure depends on the system reaching data, tools, or actions outside the intended scope, treat identity and privilege design as part of the root cause, not as a downstream hardening task. If the failure exists even with minimal authority, appsec controls are the first remediation path.

What good looks like: Red-team output should map each finding to a control owner, a containment boundary, and a measurable fix, so that model behavior, application enforcement, and access authority are all reviewed in one workflow.

Practitioner takeaway: AI red teaming is governed correctly only when the test proves both how an attack works and whether the system had the authority to make it harmful.

Related resources from NHI Mgmt Group

• How should security teams govern machine identity credentials in agentic AI environments?
• Who should own AI red teaming when identity and security controls are involved?
• Why do AI agents make non-human identity governance harder?
• Why do AI agents create new risk in non-human identity management?