AI security partnerships show identity controls are moving into the stack

At a glance

What this is: This is a partnership-focused analysis of how AI security is being embedded across enterprise security tooling, with a central finding that securing models, applications, and agents now depends on integration with identity and governance controls.

Why it matters: It matters because IAM, NHI, and security architecture teams now need to decide where AI-specific controls fit inside existing governance, rather than treating AI security as a separate project.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read TROJ.AI's analysis of AI security partnerships and ecosystem integration

Context

AI security is now a governance problem, not just a model-safety problem. As enterprises adopt GenAI apps and LLM-based agentic workflows, they are also extending the attack surface into identity, application, cloud, data, and network layers, which means existing control boundaries are no longer sufficient on their own.

TROJ.AI's article argues for an integrated security stack where AI controls complement AppSec, SecOps, cloud security, and data governance. That framing is directionally correct for IAM and NHI teams, because AI security can only be governed well when identity, access, and policy enforcement are visible across development and runtime.

Key questions

Q: How should security teams govern AI systems that use existing enterprise identities?

A: Start by mapping every AI model, application, and agent to the identities it inherits, including service accounts, API keys, and cloud roles. Then decide which permissions are genuinely necessary for build time, runtime, and monitoring. If those identities are not visible in governance processes, AI security becomes an observability exercise instead of access control.

Q: Why do AI security issues quickly become IAM and NHI problems?

A: Because AI systems rarely operate alone. They call tools, query data, and trigger workflows through existing enterprise permissions, so the risk sits in who or what can act on their behalf. Once AI actions are mediated through identities, governance has to cover entitlement scope, lifecycle, and exception handling.

Q: What do organisations get wrong when they separate AI security from SecOps and cloud governance?

A: They create fragmented response paths for a single behaviour chain. A prompt injection, a leaked secret, and an unsafe tool call may all be connected, but they will be handled as unrelated incidents unless policy, telemetry, and ownership are shared across teams.

Q: How can teams tell whether AI governance is actually working?

A: Look for evidence that AI-related access is reviewed, monitored, and revoked through normal identity processes rather than handled ad hoc. If the organisation can show clear ownership, timely review, and incident routing for AI behaviour, governance is moving beyond statements and into control.

Technical breakdown

Why AI security now depends on integration with identity and access controls

AI systems do not sit outside the enterprise control plane. When model endpoints, agent workflows, and retrieval layers interact with data stores, cloud services, and operational tools, the identity question becomes central: what is allowed to act, retrieve, or relay information at runtime? That makes AI security a distributed governance problem, not a single product category. The practical challenge is not just detecting risky prompts or toxic output, but tracing which identities, permissions, and service paths made the action possible.

Practical implication: map AI systems to the identities and permissions they inherit before you try to secure the model itself.

How runtime monitoring changes the control model for AI applications and agents

Runtime monitoring is the difference between inspecting a model in isolation and observing what it actually does in production. For AI applications and agents, runtime controls need to watch for prompt injection, data leakage, unsafe tool use, and policy violations after deployment, because the risk emerges during execution, not only during training or testing. In identity terms, this is where authorization, telemetry, and response logic need to converge.

Practical implication: treat AI runtime events as identity and policy events, not just application logs.

Why partner ecosystems matter for AI governance at enterprise scale

AI security capability is increasingly being assembled across specialist tools, cloud platforms, service providers, and governance workflows. That matters because no single control layer can cover AI development, model behavior, data access, and operational response end to end. The governance task is therefore orchestration across the security stack, with clear ownership for red teaming, policy validation, and incident handling.

Practical implication: define which team owns AI security controls at build time, runtime, and incident response before adoption accelerates.

NHI Mgmt Group analysis

AI security is becoming an identity governance problem disguised as a tooling discussion. The article is right that models, applications, and agents touch identity, cloud, data, and network controls, but the deeper issue is that runtime behaviour cannot be governed if identity context is missing. Security teams should read this as a signal that AI control design now depends on entitlement visibility, not only model inspection.

Integrated controls beat isolated AI point solutions because AI risk crosses existing trust boundaries. Prompt injection, data leakage, and unsafe agent actions all become harder to contain when identity, policy, and telemetry live in separate stacks. The field is moving toward layered enforcement, where AI-specific controls must connect to AppSec, SecOps, and cloud policy rather than sit beside them.

Agent governance will force a new form of policy orchestration. AI agents are not just another workload, because they can turn policy decisions into real-time actions across tools and data. That makes the governance question broader than detection: practitioners need to know which permissions are inherited, which are temporary, and which are effectively standing privileges in disguise.

Named concept: identity-adjacent AI risk. This is the point where AI behaviour is not governed directly through the model, but through the identities, permissions, and enforcement points surrounding it. The implication is that AI security programmes will increasingly fail or succeed based on how well they expose and control those adjacent identities.

Partnership strategy is becoming a proxy for governance maturity. When vendors build ecosystems across cloud, SecOps, AppSec, and data platforms, they are acknowledging that AI security is operationally multi-domain. Practitioners should interpret that as validation of a broader governance model, while also demanding clear control ownership instead of assuming integrations solve accountability.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For practitioners extending AI security into identity and secrets workflows, Top 10 NHI Issues frames the control failures that most often turn exposure into persistence.

What this signals

The next phase of AI security programmes will be decided less by standalone model controls and more by whether identity, data, and policy enforcement can move together. Identity-adjacent AI risk: when the AI layer inherits enterprise permissions, governance only works if those permissions are visible in the same control plane that handles incident response and recertification.

With 32.4% of security budgets already being allocated to secrets management and code security in one industry survey, the market is signalling that access control and exposure reduction are now board-level concerns, not niche implementation tasks. That trend strengthens the case for anchoring AI controls in existing identity and secrets programmes, not in isolated pilots.

Practitioners should expect more pressure to prove that AI access can be reviewed, revoked, and monitored using standard governance processes. The clearest signal is whether your AI estate can participate in ordinary access review, exception handling, and incident triage without special-case workflows or shadow ownership.

For practitioners

• Inventory AI-touching identities and permissions Document which service accounts, API keys, tokens, and platform roles can influence models, retrieval layers, or agent workflows. Include inherited permissions from cloud and data platforms, not only the AI application itself.
• Treat runtime AI events as policy events Route prompt injection, data leakage, unsafe content, and tool-use alerts into the same response workflows used for application and identity incidents. That creates a single triage path for AI behaviour that crosses security domains.
• Define control ownership across build and runtime stages Assign one accountable owner for AI red teaming, one for runtime monitoring, and one for policy enforcement so gaps do not appear between development and production. Use that ownership map in your AI governance charter.
• Validate partner integrations against governance gaps Check whether each connected tool improves visibility into identity, data access, and enforcement, or simply adds another alert source. Prioritise integrations that reduce blind spots across the AI security stack.
• Align AI security with existing identity review cycles Fold AI-related permissions into access reviews, recertification, and exception handling so agent and workload access does not sit outside standard governance cadence. This is especially important where AI systems can act across multiple platforms.

Key takeaways

• AI security is increasingly an identity and governance problem because models, agents, and applications act through existing enterprise permissions.
• The strongest control model is integrated rather than isolated, with AppSec, cloud, SecOps, and identity teams sharing ownership of AI risk.
• Practitioners should map AI behaviour to inherited access, runtime enforcement, and reviewable governance before agentic use cases expand further.

Key terms

• Agentic AI governance: The set of policies, controls, and ownership structures used to manage AI systems that can select actions and trigger tools at runtime. It extends beyond model quality into access, monitoring, and accountability for behaviour that occurs inside enterprise workflows.
• Identity-adjacent AI risk: Risk that emerges around AI systems because they operate through surrounding identities, permissions, and enforcement points rather than as isolated models. The control failure is often not the model itself, but the access paths that let the model act, retrieve, or disclose information.
• Runtime monitoring: Continuous observation of AI behaviour after deployment to detect unsafe actions, policy violations, or data exposure as they happen. In practice, it connects model behaviour with security operations, giving teams a chance to triage and contain issues while the system is active.
• AI security governance: The organisational framework that assigns responsibility for AI risk, access control, testing, and incident handling. It ties together development, security operations, and identity management so AI systems can be reviewed and controlled like other production services.

What's in the full article

TROJ.AI's full article covers the operational partnership details this post intentionally leaves for the source:

• The specific ecosystem partners and integration categories behind TrojAI's broader AI security strategy.
• The operational use cases for AI red teaming, runtime monitoring, and policy enforcement across connected tools.
• The partner-program framing for services firms, channel providers, and platform integrations.
• The product-level details of TrojAI Detect and TrojAI Defend in enterprise AI workflows.

👉 TROJ.AI's full post covers the partner program, integration areas, and platform positioning in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.