AI platform trust depends on seven controls for models and agents

At a glance

What this is: This analysis argues that “trusted AI” is an architecture test, not a label, and that seven controls determine whether models and agents are actually governable.

Why it matters: It matters because IAM, NHI, and emerging agentic AI programmes now share the same failure point: controls that look sound on paper but do not hold once runtime behaviour changes.

By the numbers:

• In an independent KU Leuven test, governed context raised agent accuracy from 62% to 92% on the same model and data.

👉 Read Collibra's analysis of what makes an AI platform trusted

Context

A trusted AI platform is one that can be held accountable for what it knows, what it can touch, and what evidence it can produce while it runs. The identity governance problem is simple: if the platform cannot prove inventory, context, and runtime control, it is not governing AI, it is describing it after the fact.

This matters most for agentic AI and non-human identities because both can make decisions or take actions outside the human review loop. The article’s core claim is that trust is earned through controls that persist at runtime, not through policy statements, and that assumption now sits at the centre of AI governance programmes.

The article is typical of the current market conversation: the language is about trust, but the real subject is controllability. For practitioners, the useful question is whether the platform can evidence who or what acted, on what data, under which policy, and with what traceability.

Key questions

Q: How should security teams govern AI platforms that run both models and agents?

A: Start with a complete inventory, then require governed context, runtime enforcement, observability, lineage, policy as code, and continuous audit evidence. If any one of those layers is missing, the platform can look compliant while still acting outside control. The governance model must cover both the asset and the actions it can take.

Q: Why do agents raise the bar for AI governance and identity controls?

A: Agents can act continuously and take consequential actions without a human in the loop, so launch-time review is not enough. That means identity, access, and data controls must work while the agent is running, not just when it is approved. The control problem becomes runtime accountability, not documentation.

Q: What do organisations get wrong about trusted AI platforms?

A: They often treat trust as a label or a dashboard score instead of a set of enforceable controls. A platform is only trustworthy if it can prove who or what acted, what it touched, and how policy was applied at the moment of execution. Without that, trust is only asserted, not demonstrated.

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

A: Look for evidence that inventory is complete, context is governed, policy is enforced during execution, and lineage can be reconstructed on demand. If you can only explain decisions after manual investigation, governance is too weak for production AI. The test is whether the platform can prove control without improvisation.

Technical breakdown

Single inventory and governed context for AI systems

A trusted platform starts with a source of record for every model, use case, and agent, plus ownership and risk tiering. That inventory is not just asset management; it is the control plane for accountability. Governed context then supplies definitions, relationships, lineage, and quality signals at runtime so the AI is not reasoning over disconnected fragments. Without those two pieces, security and governance teams cannot tell whether a decision came from a known system or an orphaned one. This is where AI control becomes an identity problem, because the subject taking action must be identifiable before it can be governed.

Practical implication: establish a single inventory and bind it to ownership, risk tier, and governed context before expanding agent use.

Runtime control, policy as code, and observability

Runtime control means the platform must enforce what the AI may reach and do while the session is live, not just at approval time. Policy as code turns access, masking, and retention rules into enforceable logic at the data layer, while observability captures traces, data-access events, and actions for audit and incident response. The point is that static review is too late for systems that can act continuously. If the platform only checks posture at launch, it has no meaningful control over what happens once the agent is running.

Practical implication: move from review-based governance to runtime enforcement with traces that prove each access decision.

End-to-end lineage and continuous audit evidence

Lineage connects source data, model input, and agent action so the organisation can answer where a decision came from and what it touched. Continuous audit evidence closes the gap between detection and proof, which matters when regulators, customers, or internal investigators ask for a reconstruction. Guardrails become meaningful only when they are backed by evidence and an immediate ability to stop or pause harmful behaviour. In identity terms, lineage and audit are the difference between knowing that an AI did something and being able to prove exactly how it did it.

Practical implication: require lineage and continuous evidence before allowing agents to influence regulated or customer-facing workflows.

Threat narrative

Attacker objective: The objective is to exploit blind spots in AI governance so an untracked model or agent can act on unverified context without enforceable constraints.

1. Entry occurs when shadow agents or orphaned models are introduced without a complete source-of-record inventory, leaving governance blind to what is actually running.
2. Escalation happens when governed context, runtime control, and policy enforcement are absent, allowing the system to act on unverified data and exceed intended reach.
3. Impact is produced when the platform cannot produce lineage, traces, or agent guardrails, so decisions cannot be reconstructed or stopped in time.

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

Trusted AI is an identity governance claim before it is a technology claim. The article is right to reject vendor labels and force a control test, because trust depends on whether the platform can identify every model and agent, govern their context, and prove actions at runtime. In practice, this makes AI governance a cross-discipline problem spanning IAM, NHI, data controls, and audit evidence. Practitioners should treat trust as a provable operating state, not a marketing term.

Runtime control is the point where most AI governance narratives fail. Access review at launch does not govern an agent that keeps acting after approval, and policy stored in a document does not constrain data access during execution. That gap is not a missing feature, it is a broken control model. Practitioners should re-evaluate any programme that still assumes static permissioning is sufficient for dynamic AI behaviour.

Governed context is a named control gap, not a nice-to-have enhancement. The KU Leuven result cited in the article, from 62% to 92% accuracy, shows that grounding changes outcomes materially, but the governance significance is broader: without context, identity and access decisions can be correct about the actor and wrong about the meaning. Practitioners should connect context quality to access trust, not just model performance.

Continuous evidence is what makes AI governance auditable rather than aspirational. If a platform cannot reconstruct who acted, on what data, and under which policy, then incident response and regulatory review both collapse into inference. That is especially true where models and agents touch regulated data or customer-facing workflows. Practitioners should regard evidence production as a control, not a reporting afterthought.

Shadow agents create the same accountability problem that shadow IT created, but with faster impact. A single inventory is not just about discovery, it is about preventing autonomous or semi-autonomous systems from operating outside governance because nobody owns them. The practical conclusion is that inventory, ownership, and risk tiering must be enforced as an identity control surface, not maintained as a spreadsheet.

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.
• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
• For a broader view of how identity governance breaks down across machine and autonomous systems, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Trusted AI will increasingly be judged by runtime proof, not policy language. The practical signal for IAM and security teams is whether inventory, access control, lineage, and audit artefacts can be produced without manual reconstruction. As AI systems become more operational, the gap between declared governance and enforceable governance will become the primary programme risk.

Governed context is becoming a control dependency, not a model optimisation. When context quality changes decision quality as sharply as the article’s cited result suggests, organisations need to treat context curation as part of identity and access governance, not only data engineering. That shift should be mapped into operating models and ownership, especially where agents interact with regulated or customer data.

Identity teams should expect more pressure to align AI governance with NHI lifecycle controls. The same discipline used to track service accounts, secrets, and workload identity now needs to extend to models and agents that can act on live data. For teams building their control baseline, the AI LLM hijack breach analysis shows how quickly compromised credentials can turn into platform-level trust failures.

For practitioners

• Inventory every model and agent Create a single source of record with owner, risk tier, data access scope, and business purpose for every AI system before it reaches production. Tie onboarding to approval and offboarding to removal so shadow agents cannot persist outside governance.
• Enforce policy at runtime Move access, masking, and retention rules into code that evaluates when the AI reaches for data, not only when the system is reviewed. Confirm that denied actions are blocked during live execution rather than merely logged after the fact.
• Require traceable decision evidence Capture decision traces, data-access events, and lineage from source to model input to agent action so each outcome can be reconstructed under audit or incident review. Make evidence retention part of the control design, not an after-the-fact export.
• Add kill-switch governance for agents Define who can pause or disable an agent when its behaviour drifts, and test that intervention path in production-like conditions. If you cannot stop the agent quickly, your guardrails are advisory rather than enforceable.

Key takeaways

• Trusted AI is not a branding claim, it is a control stack that must hold at runtime.
• Inventory, governed context, runtime enforcement, lineage, and audit evidence are the points where AI trust is either proven or lost.
• Practitioners should redesign AI governance around accountable execution, not around launch-time approval alone.

Key terms

• Governed Context: Governed context is the trusted meaning and metadata an AI system uses at runtime to interpret data correctly. It includes definitions, relationships, lineage, and quality signals so decisions are grounded in verified context rather than fragmented or stale information.
• Runtime Control: Runtime control is the ability to limit what an AI system can access or do while it is actively running. It matters because launch-time approvals do not stop an agent or model from overreaching once execution begins, especially when data and action paths are dynamic.
• End-to-end Lineage: End-to-end lineage is the trace from source data to model input to agent action. It lets teams reconstruct how a decision was made and what it touched, which is essential for auditability, incident response, and accountability when AI outcomes are disputed.
• Agent Guardrail: An agent guardrail is a control that constrains or halts an AI agent when behaviour drifts beyond policy. In practice, it only has value when it is paired with evidence, enforcement, and a clear authority to pause the agent before harm compounds.

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 governance in your organisation, it is worth exploring.

This post draws on content published by Collibra: What makes an AI platform 'trusted'? 7 non-negotiables for governing models and agents. Read the original.