TL;DR: Enterprises lack a single view of agent behaviour as Unity AI Gateway governs agents inside Databricks but cannot extend across Snowflake, Bedrock, Copilot Studio, CrewAI, or in-house systems, according to Trust3. The core issue is that access review and static authorization assume stable, reviewable privilege, while agents need just-in-time, task-scoped control and revocation tied to runtime purpose.
At a glance
What this is: Trust3 examines why platform-native governance for AI agents stops at the vendor boundary and cannot cover multi-platform agent estates.
Why it matters: IAM, IGA, PAM, and AI governance teams need a control model that follows agent runtime behaviour across platforms, or they will keep certifying static entitlements while agents operate outside those review cycles.
Context
AI agent governance is the set of controls that determines what an agent can discover, observe, and do at runtime. The article argues that those controls cannot be left inside a single platform when agent estates span multiple clouds, SaaS systems, and in-house frameworks.
The governance gap is not about model quality or application feature sets. It is about whether policy can be enforced inline across every agent decision, with just-in-time authorization, task-scoped expiry, and a usable audit trail that survives platform boundaries.
Key questions
A: Governance breaks when control stays detached from the tools, data sources, and workflows used by AI systems. Teams lose visibility into actual access paths, policy drift goes unnoticed, and enforcement becomes inconsistent. Effective AI governance needs integration points that connect policy decisions to the operational environment where AI runs and interacts with data.
Q: Why do just-in-time grants matter for AI agent access?
A: Agents act at runtime, so access that persists after the task creates unnecessary exposure. Just-in-time grants limit privilege to the declared purpose and task duration, which reduces the period in which an agent can misuse access or carry entitlement into a later action.
Q: How do security teams know if agent governance is actually working?
A: It is working only if the team can answer three questions quickly for any agent: what it can reach, what it did recently, and whether that behaviour matches intent. If any of those answers require manual reconstruction, governance exists on paper but not in operations.
Q: What should teams do when an agent platform cannot govern outside its own ecosystem?
A: Treat platform-native controls as local enforcement, then add a vendor-neutral layer for policy, audit, and revocation across the full agent portfolio. That is the only way to keep governance consistent when agents move across models, clouds, and applications.
Technical breakdown
Why platform-native governance stops at the control boundary
Platform-native agent governance is effective only inside the ecosystem that issues it. Once agents move across Snowflake, Bedrock, Copilot Studio, CrewAI, or internal APIs, the platform loses line of sight and policy consistency becomes fragmented. The practical issue is not whether each platform can govern its own agents, but whether the enterprise can apply one decision model across all of them without relying on manual reconciliation after the fact.
Practical implication: Treat vendor-native governance as a local control, not an enterprise control plane.
Discover, observe, secure: the runtime control loop for agents
The article’s three-step model maps cleanly to agentic governance. Discover means identifying sanctioned and unsanctioned agents from runtime traffic, registries, and logs. Observe means capturing prompts, retrievals, and tool calls as they happen. Secure means authorizing each action at the moment it fires and writing an immutable audit entry. This is a runtime model, not a retrospective reporting model, because agents act continuously and can change scope between calls.
Practical implication: Design governance around live enforcement points, not after-the-fact visibility.
Why static authorisation fails for task-scoped agent access
Static authorization assumes the system can be safely pre-declared and left alone until review. Agent governance breaks that assumption because access should exist only for the task and only for the declared purpose. That means the control must issue a just-in-time grant, bind it to the agent identity and purpose, and revoke it when the task ends. Without that lifecycle, standing access outlives the work it was meant to support.
Practical implication: Move from standing entitlements to task-scoped grants with explicit expiry.
NHI Mgmt Group analysis
Vendor-native agent governance creates a portfolio blind spot: a control plane that only sees agents inside one platform cannot govern an enterprise that runs agents across multiple clouds and frameworks. That is not a feature gap, it is a boundary problem. The practitioner consequence is that policy, audit, and revocation must be evaluated at the portfolio layer, not the product layer.
Just-in-time access is now the governing assumption for agent estates: agents do not fit review cycles built around long-lived privilege. If access persists long enough to be certified, the control is already too slow for the runtime it is meant to govern. The implication is that governance programs need to treat access duration as a first-class control signal, not a by-product of provisioning.
Discover, observe, secure is the right operating model for agentic AI governance: discovery without live observation leaves unknown agents unchecked, and observation without inline security leaves them merely visible. The named concept here is the runtime governance gap, where policy exists in principle but not at the point of action. Practitioners should measure whether each agent decision can be identified, justified, and enforced in the same flow.
Static authorization assumes agent purpose is stable enough to pre-approve: that assumption fails when an agent can chain prompts, tool calls, and retrievals across systems in one task. The implication is that control design must account for runtime purpose drift, because the enterprise cannot govern what it only understands after execution.
Accountability now follows the control plane, not the host platform: when agents span Databricks, Snowflake, SaaS, and internal APIs, no single workload owner can explain the full decision trail alone. The practitioner conclusion is that governance, audit, and revocation ownership need a cross-platform operating model before agent sprawl becomes unanswerable.
What this signals
Runtime governance gap: the real problem is not whether a single platform can describe its own agents, but whether an enterprise can enforce policy across every runtime where those agents appear. Once the estate spans multiple clouds and frameworks, governance has to follow execution rather than platform ownership.
Agent governance shifts the control question from what is permitted in principle to what can be enforced at the moment of action. That means practitioners should design for discovery, observation, and secure inline decisions rather than relying on periodic review cycles that arrive too late.
Access review logic still assumes privilege persists long enough to be examined. For AI agents, that assumption is fragile, so identity and governance teams need controls that bind access to declared purpose, task duration, and immediate revocation.
For practitioners
- Map agent estates across platforms Inventory agents discovered through runtime traffic, framework registries, and gateway logs, then reconcile that list with what each platform claims to govern.
- Bind authorisation to declared purpose Require each agent action to carry a declared purpose that is checked at the moment of execution, not just at onboarding or provisioning.
- Replace standing access with task-scoped grants Issue access only for the task the agent is performing and revoke it as soon as the task completes, so privilege does not persist beyond the work.
- Test revocation under platform outage Validate that compiled policy at enforcement points keeps blocking new access when the control plane is unreachable, and confirm that revocation still fails static rather than failing open.
Key takeaways
- AI agent governance breaks down when controls stop at the vendor boundary and cannot follow the agent across platforms.
- The article’s core model is discover, observe, secure, which turns governance into a live enforcement problem rather than a retrospective one.
- Practitioners should move from standing access and static approval models to task-scoped grants, declared purpose checks, and immediate revocation.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centers on agent identity, privilege scope, and cross-platform authorization boundaries. |
| ASI02 — Tool Misuse | The article focuses on governing live tool calls made by agents across systems. | |
| Recommendation — Apply ASI03 to bind agent privilege to declared purpose and runtime scope across platforms. Use ASI02 to control and log every tool call an agent can invoke at runtime. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agent access that persists beyond task completion is an overprivilege problem. |
| Recommendation — Reduce NHI-05 risk by replacing standing agent entitlements with task-scoped grants. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about governance ownership and cross-platform accountability for AI agents. |
| Recommendation — Use GOVERN to define ownership, auditability, and enforcement responsibilities across the agent estate. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust principle: continuous verification — Continuous Verification | The runtime authorization model depends on verifying each agent action as it occurs. |
| Recommendation — Apply continuous verification to every agent decision instead of trusting prior approval alone. | ||
Key terms
- Model-Neutral Control Plane: A governance layer that applies the same policy, logging, and cost rules across multiple AI models and hosting patterns. For agentic systems, neutrality is required when no single vendor should become the sole trust boundary for enterprise traffic.
- Task-Scoped Access: Task-scoped access is permission granted for one defined purpose and removed once the task is complete or the session expires. For non-human identities, it reduces standing privilege and limits how long an attacker can exploit a stolen credential.
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Discover, Observe, Secure: Discover, Observe, Secure is a governance pattern for finding agents, capturing their behavior, and enforcing policy inline. It is especially relevant where AI agents span multiple platforms, because visibility alone does not stop action and static policy alone does not reflect live behavior.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 22, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org