By NHI Mgmt Group Editorial TeamDomain: AI SecuritySource: OneTrustPublished June 9, 2026

TL;DR: Homegrown AI governance can work for a small number of low-risk AI use cases, but it falls short as volumes, risk tiers, and documentation obligations grow under frameworks such as the EU AI Act, according to OneTrust. The practical issue is not inventory alone, but whether governance decisions, evidence, and runtime controls can be reused consistently across agents and connected systems.


At a glance

What this is: This analysis argues that homegrown AI governance tooling breaks down when organisations need repeatable decisions, risk memory, and runtime enforcement across high-volume, high-risk AI use cases.

Why it matters: It matters to IAM and security teams because AI governance now depends on identity, access control, auditability, and policy enforcement that extend beyond intake into runtime.

By the numbers:

👉 Read OneTrust's analysis of buy versus build decisions for AI governance tooling


Context

AI governance is moving from point-in-time review to continuous control over how systems are approved, monitored, and constrained. In that shift, homegrown intake tools often remain useful for basic triage, but they struggle once organisations need durable decision history, policy reuse, and runtime enforcement across multiple AI systems.

The identity angle is real because agents, model connectors, and tool integrations depend on permissions, approvals, and audit trails. Once AI systems can call tools, write records, or change configuration, governance becomes inseparable from IAM, secrets management, and access control rather than a standalone committee workflow.


Key questions

Q: What fails when AI governance is handled only through homegrown intake workflows?

A: Homegrown intake workflows fail when organisations need repeated, defensible decisions at scale. They can record an approval, but they often cannot preserve the prior reasoning, control outcomes, and exception history needed to judge the next similar case consistently. That leaves teams re-litigating the same decisions while runtime governance remains under-enforced.

Q: Why do AI-era threats force security teams to rethink identity controls?

A: Because AI increases the speed and scale of identity events. Attackers can generate more lures, test more paths, and reach more systems before manual review catches up. Identity controls still matter most, but they need better scoping, faster detection, and cleaner accountability so security teams can respond before abuse spreads.

Q: How do security teams know if AI governance is working?

A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent. If the team cannot explain who owns an AI workflow, what it can reach, and when its access was last reviewed, governance is incomplete. Control maturity shows up in traceability, not adoption volume.

Q: Should organisations buy AI governance tooling before scaling agentic workflows?

A: If the organisation expects many AI use cases, regulated decisions, or connected runtime actions, purpose-built tooling is usually easier to sustain than a bespoke stack. The decision should hinge on whether the current process can support policy enforcement, auditability, and decision reuse across systems. If it cannot, scale will expose the gap quickly.


Technical breakdown

Why homegrown AI governance tools hit a scaling wall

Homegrown governance tools usually start as intake forms, workflow approvals, and documentation tracking. That works when the organisation has a small number of low-risk use cases, because the main task is deciding whether a project should proceed. The problem appears when similar requests multiply, risk levels vary, and teams need to compare new proposals against past decisions. At that point, the tool must hold context, patterns, evidence, and policy outcomes, not just a queue. Without that memory layer, every review becomes a one-off exercise.

Practical implication: evaluate whether your current process stores reusable decision context, not just approval records.

Agent governance, MCP, and the spread of runtime policy

Agent governance changes the operating model because policies must travel with the request as it moves across tools and data sources. MCP, or Model Context Protocol, increases the need for this because it lets agents connect dynamically to external systems. That means governance can no longer stop at approval time. Organisations need to know which identity is acting, what it can reach, what it is allowed to do, and how those permissions are enforced in real time. This is where access control, auditability, and policy checks become operational controls rather than paperwork.

Practical implication: design governance so policy enforcement follows the agent across systems, not just the initial review.

Why risk memory matters more than inventory

An AI inventory tells you what exists, but it does not tell you how similar cases were judged, which controls worked, or whether a previous exception should be repeated. Risk memory is the ability to retain those decisions and reuse them across future assessments. In practice, this supports pattern matching, faster approvals for known low-risk cases, and more scrutiny for novel or high-risk cases. Without it, teams reinvent the same reasoning each time, which slows governance and weakens consistency across the AI estate.

Practical implication: treat decision history as governance evidence, not administrative clutter.


Threat narrative

Attacker objective: The objective is to exploit governance gaps so AI systems gain broader operational reach than the organisation can justify, audit, or constrain.

  1. Entry begins when a new AI initiative, agent, or workflow enters a manual intake and triage process that was designed for a small number of cases.
  2. Escalation occurs when similar approvals, policy exceptions, and control decisions accumulate faster than the committee can compare and reuse prior judgments.
  3. Impact follows when runtime permissions, auditability, and enforcement do not keep pace, allowing AI systems to act beyond intended scope.

NHI Mgmt Group analysis

Homegrown AI governance breaks when decision volume becomes the control plane. Intake tooling can support low-volume review, but it becomes brittle when teams need repeatable risk decisions, evidence reuse, and policy memory across many similar use cases. The article's core point is that governance is no longer a committee artifact when AI moves into operational execution. Practitioners should treat decision orchestration as a governed capability, not a spreadsheet problem.

Agent governance creates a genuine identity problem, not just an AI workflow problem. Once agents can connect through MCP and similar interfaces, the real question becomes which identity is acting, what permissions it inherits, and how those permissions are reviewed and enforced. That brings IAM, access control, and auditability into the centre of AI governance design. Practitioners should expect identity teams to own part of the control architecture.

Risk memory is the named concept this market needs. Organisations need a durable way to retain past decisions, control outcomes, and exception history so new AI proposals can be judged against prior evidence. Without that memory, every approval starts from zero, which creates inconsistency and slows safe adoption. The practitioner conclusion is simple: governance platforms must preserve institutional judgement, not just workflow state.

Runtime guardrails matter more than documentation once agents can act across systems. The article correctly shifts the conversation from policy paperwork to enforcement, because agents that trigger workflows or change configurations need controls that operate where the action occurs. Documentation remains necessary for compliance, but it is not enough to stop overreach. Practitioners should prioritise control points that can intervene during execution, not only before it.

What this signals

Risk memory becomes the differentiator between governance and administration. Once AI use cases start to multiply, the programme needs a durable way to reuse prior decisions, preserve exceptions, and connect approvals to enforcement. Without that layer, the organisation will keep generating policy artefacts while operating in a high-friction manual loop. For identity and AI governance teams, the real task is to make the decision trail operational, not archival.

The next phase of AI governance will be judged by whether it can control action, not just intent. That means security and IAM leaders should expect stronger pressure for runtime policy checks, clearer agent identities, and better linkage between approvals and tool-level permissions. The organisations that can connect review, access, and enforcement will absorb agentic growth with less governance debt.


For practitioners

  • Inventory repeat-decision use cases Map every AI intake flow that repeats similar approvals, exception decisions, or control checks, and identify where your current process forces manual re-review instead of reuse of prior judgments.
  • Tie governance to runtime identity Require each AI system, connector, and agent workflow to present a clear identity, scoped permissions, and auditable action trail before it can reach production data or tools.
  • Separate low-risk and high-risk lanes Create a fast path for known low-risk use cases and a stricter path for novel or regulated use cases, so committees spend time where the residual risk is highest.
  • Test policy enforcement beyond intake Validate that approvals translate into enforced controls inside connected tools, including access checks, logging, and stop conditions when agent behaviour deviates from approved intent.

Key takeaways

  • Homegrown AI governance tools can manage intake, but they struggle once organisations need reusable decisions, control memory, and runtime enforcement at scale.
  • Agentic AI turns governance into an identity and access problem because permissions, auditability, and control checks must travel with the system as it acts.
  • Practitioners should judge AI governance tooling by its ability to preserve decision history and enforce policy inside connected systems, not by how many forms it can route.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF, NIST AI 600-1, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10A2The article centres on agent governance and runtime control gaps.
NIST AI RMFGOVERNThe piece is about governance, accountability, and policy memory for AI systems.
NIST AI 600-1The article discusses governance of GenAI and agentic workflows in enterprise settings.
NIST Zero Trust (SP 800-207)Agents that move across systems need continuous verification and scoped access.
NIST CSF 2.0PR.AC-4The article repeatedly ties governance to permissions, auditability, and enforcement.

Use the profile to align AI governance controls with approved use cases and documented exceptions.


Key terms

  • AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
  • Risk Memory: Risk memory is the retained record of past risk decisions, exceptions, and control outcomes that can be reused when similar AI use cases appear. It reduces repeated manual work and helps teams judge new proposals against known patterns rather than starting from scratch each time.
  • Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
  • Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

What's in the full article

OneTrust's full blog covers the operational detail this post intentionally leaves for the source:

  • How the vendor frames intake, triage, and documentation workflows for AI governance at scale.
  • The specific ways high-risk use cases drive compliance obligations under the EU AI Act and similar regimes.
  • How the article describes context graphs, decision memory, and reuse of prior approvals.
  • The vendor's view of where runtime governance starts to replace committee-led review.

👉 OneTrust's full blog covers the scaling limits of homegrown governance and the role of runtime control.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners align identity controls with the operational realities of AI systems and other non-human identities.
NHIMG Editorial Note
Published by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org