AI agent governance needs runtime controls beyond AI TRiSM

At a glance

What this is: This is Zenity’s analysis of how Gartner’s AI TRiSM framework maps to AI agent governance, with the key finding that runtime visibility and enforcement matter more than static policy alone.

Why it matters: It matters because IAM, IGA, and security teams now have to govern AI agents as active identities with tool access, data access, and downstream effects, not as simple automation.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Zenity's analysis of AI TRiSM for AI agent governance

Context

AI agent governance is the problem of controlling software entities that can decide, act, and interact with tools or data sources on their own. In this article, Zenity argues that the security gap is not model quality alone, but the absence of visibility, accountability, and runtime enforcement once agents begin operating across enterprise systems.

That framing matters for identity programmes because AI agents are not just another automation layer. They behave like non-human identities with expanding access paths, which means IAM, IGA, PAM, and secrets governance all need to account for agent behaviour, not only assigned permissions.

Key questions

Q: How should security teams govern AI agents that can access business systems?

A: Security teams should govern AI agents as non-human identities with ownership, scoped permissions, and runtime enforcement. That means inventorying agents, defining allowed tools and data paths, reviewing access regularly, and capturing execution evidence so behaviour can be audited. If the agent can act across systems, governance has to track both entitlement and activity.

Q: Why do AI agents complicate IAM and IGA programmes?

A: AI agents complicate IAM and IGA because they are not static users and they do not always behave predictably within a fixed role. Their access can expand through integrations, data flows, and delegated tool use, which makes provisioning alone insufficient. Teams need lifecycle controls plus runtime oversight to keep scope aligned with intent.

Q: What do teams get wrong about AI agent visibility?

A: Teams often think inventory alone is enough, but visibility without behavioural context does not show what an agent actually did. To be useful, visibility must link the agent to owners, data access, tool calls, and policy outcomes. Otherwise, the organisation can detect that an agent exists without understanding the security impact of its actions.

Q: Who should be accountable when an AI agent violates policy?

A: Accountability should sit with the business owner of the agent, the security team defining control requirements, and the platform team operating the runtime safeguards. If no one owns the agent’s purpose and permissions, policy exceptions become permanent and review becomes meaningless. Accountability only works when the agent is treated as a governed identity, not a background feature.

Technical breakdown

AI TRiSM for AI agents: governance and runtime enforcement

AI TRiSM separates governance from runtime control. Governance covers cataloguing AI assets, assigning ownership, mapping data flows, and approving use, while runtime enforcement inspects what an agent actually does during execution. For AI agents, that distinction matters because a policy on paper does not prevent a tool call, a data share, or an unauthorized downstream action. Zenity’s framing is that the top of the TRiSM stack is where agent behaviour becomes visible and enforceable, especially when agents interact with cloud apps, productivity tools, and enterprise data.

Practical implication: treat agent governance and runtime enforcement as two separate control layers, not one checkbox.

AI agent observability and audit trails

Observability in this context means recording who interacted with an agent, what data flowed through it, and which tools or functions it invoked. That creates an audit trail that can support compliance, incident review, and policy enforcement. Without that trail, teams may know an agent exists but not whether it exposed sensitive data, executed an unsafe function, or crossed an expected boundary. The core problem is not lack of activity logs in general, but lack of identity-aware traces that connect agent actions to ownership and policy.

Practical implication: require identity-linked telemetry for every agent action that touches data or invokes tools.

Shadow AI and over-permissioned agent access

Shadow AI describes unmanaged agents operating outside formal oversight while still reaching enterprise systems. Over-permissioned agents are the same risk expressed through entitlement: the agent has more access than its job requires, which widens blast radius when behaviour drifts. Zenity’s article places this in the AI TRiSM context because traditional DLP, DSPM, and IAM controls often see the data or credential, but not the agentic decision path that used them. That makes misconfiguration and unsanctioned integration the real failure mode.

Practical implication: inventory unmanaged agents and review their access paths before they are allowed to connect to business systems.

Threat narrative

Attacker objective: The objective is to exploit agent behaviour and existing permissions to reach data, systems, or actions the organisation did not intend to expose.

1. Entry occurs when an AI agent is connected to enterprise tools, data sources, or user workflows without sufficient governance or ownership controls.
2. Escalation happens when the agent uses granted permissions to access sensitive data, invoke unauthorized functions, or chain actions across systems beyond intended scope.
3. Impact appears as data exposure, unauthorized system access, or policy violations that are difficult to reconstruct without runtime traces.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent governance is becoming an identity problem before it is a model problem. Once an agent can access tools, data, and downstream workflows, the security question shifts from model safety to entitlement control, ownership, and runtime enforcement. That is why AI TRiSM matters to identity teams: it turns agent behaviour into a governable identity surface, not just an application risk. The implication is that IAM and IGA teams have to treat agent activity as part of the access estate.

Runtime inspection is the control plane that static policy cannot replace. Static approval, policy definitions, and inventory alone do not stop an agent from making a harmful choice during execution. Zenity’s framing reinforces a broader NHI principle: if the actor can act at runtime, then governance must observe runtime, not just provisioning time. Practitioners should read this as a failure of control placement, not a tooling shortage.

Shadow AI creates an unowned identity layer inside the enterprise. The issue is not merely undiscovered software, but undiscovered software that can act with credentials, data access, or delegated trust. That makes the governance gap cross-domain, affecting IAM, PAM, secrets management, and compliance evidence at the same time. The practical takeaway is that agent discovery must be tied to ownership and access review, or the environment will accumulate hidden non-human identities.

AI TRiSM is a useful organising model only if teams resist reducing it to a compliance label. The article is strongest when it connects policy, observability, and enforcement into one operating model for AI agents. That is the right direction for the market: governance is no longer just documentation, and security is no longer just detection. Practitioners should use AI TRiSM to decide where enforcement lives, who owns the agent, and what evidence proves control.

AI agent governance belongs in the same programme family as NHI lifecycle management. Agents now need cataloguing, attestation, access review, and revocation logic just like other machine identities, but with stronger runtime scrutiny because they can choose actions mid-session. The discipline is converging on one fact: if an identity can act without a human in the loop, the governance model must assume active, not passive, behaviour. Practitioners should align agent governance with NHI controls instead of treating it as a separate exception.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• The next governance question is whether agent oversight is being built as a runtime control plane, or left as a static policy layer that cannot see behaviour in motion, according to OWASP NHI Top 10.

What this signals

AI agent governance is converging on the same operational pattern as NHI lifecycle management. The programme question is no longer whether agents exist, but whether they are catalogued, owned, reviewed, and revoked with the same discipline applied to other non-human identities. With 80% of organisations reporting agent behaviour beyond intended scope, the governance gap is already operational, not theoretical.

Shadow AI should now be treated as an identity discovery problem. If an agent can invoke tools and move data without clear ownership, the organisation has created an untracked identity layer inside its own environment. That is why agent inventory, access review, and telemetry need to be linked to policy enforcement, not managed as separate projects.

Runtime control will matter more than posture reports as agent adoption scales. Static risk scoring can show exposure, but it cannot stop a session from crossing a boundary. The practical shift is toward continuous inspection of function calls, tool use, and data access, with the OWASP Agentic AI Top 10 providing a useful threat-modeling reference.

For practitioners

• Build an agent inventory with ownership fields Record every AI agent, its business owner, data sources, connected tools, and approved purpose so you can review access and behaviour against a known baseline. Link the inventory to access reviews and exception handling so shadow AI does not remain unowned.
• Separate policy definition from runtime enforcement Define what an agent is allowed to do, then enforce those rules during execution with inspection of inputs, outputs, and function calls. Use runtime controls for blocking, alerting, or step-up review when an agent crosses an approved boundary.
• Tie agent telemetry to compliance evidence Capture who interacted with each agent, what data it touched, and which downstream tools it invoked, then retain that evidence for audit and incident response. This is what turns AI usage from a black box into an accountable control surface.
• Review over-permissioned agents before scale-up Prioritise agents with access to sensitive systems, proprietary data, or write permissions in business applications. Reduce standing access, remove unnecessary integrations, and validate whether the current access path matches the agent’s intended function.

Key takeaways

• AI agents are now an identity governance issue because they can act across tools, data, and workflows without built-in security policy.
• Visibility alone is not enough, because runtime behaviour is where an agent crosses from approved use into policy violation.
• Teams should connect agent inventory, ownership, access review, and runtime enforcement before adoption expands further.

Key terms

• AI TRiSM: AI TRiSM is a governance model for trust, risk, and security management around AI systems. In practice it combines policy, inventory, posture review, and runtime enforcement so organisations can see what AI is doing and stop behaviour that crosses approved boundaries.
• AI Agent Observability: AI agent observability is the ability to trace what an agent did, what data it touched, and which tools or actions it invoked. For security teams, it turns agent activity into evidence that supports audit, policy enforcement, and incident response.
• Shadow AI: Shadow AI is the use of AI agents or AI services outside formal oversight or approved governance. The security risk is not only unknown usage, but unknown usage with access to enterprise data, tools, or credentials, which makes accountability and review difficult.
• Runtime Enforcement: Runtime enforcement is control applied while an agent is operating, not just when it is configured or approved. It matters because an agent can still make unsafe decisions after deployment, so inspection and blocking need to happen during execution, when behaviour becomes visible.

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 programme maturity, it is worth exploring.

This post draws on content published by Zenity: How Zenity Helps Enterprises Apply AI TRiSM to AI Agents. Read the original.