TL;DR: Agentic AI deployment is cutting across DLP, model security, and application security in ways existing frameworks do not fully address, while the Trump Administration’s AI Executive Order signals stronger federal hardening and cybercrime enforcement, according to Zenity. The compliance gap is already structural, because current governance models assume bounded tools and stable authorization paths, not runtime decision-making by AI agents.
At a glance
What this is: This is Zenity’s live briefing on how emerging AI regulation intersects with agentic AI security, with a focus on the governance gaps that current enterprise controls leave open.
Why it matters: It matters to IAM, IGA, PAM, and security architecture teams because agent identities change the compliance problem from static access control to runtime governance across DLP, model security, and application security.
👉 Register for Zenity's live briefing on governing AI agents ahead of regulation
Context
Agentic AI security is becoming a governance problem before it becomes a product category problem. Enterprises are being asked to secure AI agents that can cross application, model, and data boundaries while policy frameworks still treat access as if it were stable, reviewable, and human-directed.
Zenity frames the discussion around regulation because policy pressure is now moving in the same direction as the technology. For IAM and NHI programmes, that means the immediate question is not whether regulation arrives, but which existing controls fail first when agents operate across toolchains and decision layers.
Key questions
Q: How should security teams govern AI agents before regulations are finalized?
A: Treat agent governance as a live control problem, not a policy placeholder. Security teams should inventory agent actions, map delegated access paths, and define runtime guardrails for tool use, data access, and approval boundaries. The aim is to create evidence and enforcement now, so future compliance requirements map onto existing operating controls instead of forcing a rushed redesign.
Q: Why do AI agents create a gap in existing IAM and PAM programmes?
A: Because IAM and PAM are usually built around stable identities and predictable access events. AI agents can initiate actions, chain tools, and change execution paths during runtime, which means the security problem is behavioural as well as credential-based. Teams need to govern what the agent can do during execution, not just what account it used to sign in.
Q: What signals show that an AI agent is operating outside governance boundaries?
A: Look for cross-system tool calls that were not part of the approved workflow, repeated data pulls beyond task scope, and actions that cannot be tied to a clear owner or policy justification. If the evidence cannot explain why the agent acted, the governance boundary is too loose for compliance use.
Q: What should organisations do when agent regulation starts to harden?
A: They should be able to show who owns each agent, what the agent may access, how decisions are logged, and which controls stop unauthorized chaining of actions. The strongest programmes will already have evidence-ready processes, so regulatory change becomes a mapping exercise rather than a crisis response.
Background and context
Why agentic AI security escapes traditional control boundaries
Agentic AI deployment does not fit neatly into one control domain. DLP sees sensitive data movement, model security sees prompt and output risk, and application security sees tool invocation and workflow abuse. The failure is in the seams, where each control family assumes it owns the whole problem but actually only sees one stage of agent behaviour. For identity teams, this means the agent is not just another workload. It is a runtime decision-maker whose access path can change during execution, which makes static entitlement thinking incomplete.
Practical implication: Map agent behaviour across DLP, model, and application controls before assigning ownership to a single team.
What federal AI policy signals mean for enterprise governance
The briefing points to the Trump Administration’s AI Executive Order as a signal of direction, not a final compliance blueprint. The policy emphasis on federal system hardening, voluntary frontier model frameworks, and enforcement against AI-enabled cybercrime suggests regulators are moving toward operational accountability, not just model documentation. That matters because enterprise controls often focus on procurement and approval, while policy attention is shifting toward how agents are built, deployed, and used in practice.
Practical implication: Track policy themes now so governance, procurement, and security standards can be aligned before mandates arrive.
Why existing regulations leave an agent governance gap
Most current regulations were written for software systems, human users, or classic machine identities. Agentic AI introduces a more fluid identity pattern, where access may be delegated, recombined, and executed with context that changes at runtime. That makes conventional lifecycle controls necessary but insufficient. The core gap is not simply lack of rules, but lack of a governance model for identities that initiate action rather than only respond to requests.
Practical implication: Treat agent governance as a distinct control plane, not as a variant of human IAM or standard workload identity.
NHI Mgmt Group analysis
Agentic AI regulation is exposing a control-plane gap, not just a policy gap. The real issue is that current enterprise governance often assumes access can be authorized, logged, and reviewed after the fact. Agentic systems compress decision and execution into the same runtime window, so that assumption breaks before compliance teams can even measure it. The implication is that agent governance has to be designed as a continuous control plane, not an audit afterthought.
Agentic AI changes identity from static entitlement to runtime authority. Traditional IAM and PAM models are built around identifiable subjects, predictable request flows, and stable privilege boundaries. Agents can select tools and act across systems in ways that are not fully predetermined by the workflow owner, which means the subject of governance is the behaviour of the runtime, not just the account behind it. Practitioners should treat identity as an execution condition, not just a login event.
Regulation will likely follow the operational failure modes, not the marketing language. The briefing’s policy lens suggests future oversight will focus on where agents touch data, how they invoke tools, and who is accountable when those actions cross system boundaries. That lines up with NIST AI Risk Management Framework thinking and with broader zero trust principles, but the practical pressure will be on evidence, not intent. Security leaders should prepare for controls that can demonstrate bounded agent action.
Runtime agent authority is the named governance concept that matters here. It describes the point where an AI agent’s permission to act becomes a live security condition rather than a static entitlement. Once that condition exists, access reviews and approval workflows are no longer enough on their own, because the risk is created during execution. Practitioners need to rethink where authority starts, how long it lasts, and what evidence proves it was constrained.
Agent governance will converge with NHI governance, but it will not be identical to it. AI agents are still non-human identities, so the underlying discipline of secrets, entitlement scope, and lifecycle ownership remains relevant. But autonomy changes the governance burden because the question is not only who has the credential, but what the credential can trigger at runtime. Teams that collapse agents into generic workload identity risk missing the behavioural layer that makes them materially different.
From our research:
- 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.
- 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 a deeper control-plane view, OWASP Agentic Applications Top 10 maps the runtime abuse patterns that policy must eventually address.
What this signals
Runtime agent authority is becoming the practical dividing line for security teams. Once an AI system can decide, select, and execute within a single runtime loop, legacy approval and recertification cycles stop being the right unit of control. The programme impact is immediate: governance must move closer to execution, with evidence that survives both audit and incident response.
The policy signal is that regulation will increasingly ask for operational proof, not architectural promises. That means teams should prepare to document tool boundaries, delegated permissions, and accountable owners in a form that can be inspected quickly. In practice, this is the same discipline that NIST Cybersecurity Framework 2.0 pushes toward under governance and protective outcomes.
For IAM leaders, the near-term test is whether agent behaviour can be separated cleanly from human and workload identity reporting. If not, agent activity will disappear into generic logs and create false confidence. Security teams should therefore treat agent inventory, runtime logs, and approval evidence as a single governance dataset, not three disconnected reports.
For practitioners
- Inventory every agentic workflow Identify where AI agents can access tools, data, and downstream systems, then map which team owns each decision point. Include indirect delegation paths and embedded agents inside platforms, because hidden runtime access is where governance usually fragments.
- Define runtime guardrails for agent authority Set explicit limits on what an agent can invoke, when it can act, and which approvals or policy checks must fire before cross-system execution. Focus on runtime enforcement, not policy documents that sit outside the execution path.
- Align policy, legal, and security evidence Translate emerging AI regulation into evidence requirements for logging, approvals, data handling, and accountability. Make sure the controls produce artifacts that can support audits, incident reviews, and internal exception handling.
- Separate agent governance from generic workload identity Use workload identity controls for the baseline, but add agent-specific review for tool selection, action chaining, and data access scope. The control objective is to bound behaviour, not just to authenticate the actor.
Key takeaways
- Agentic AI regulation is arriving against a control gap that existing IAM, DLP, and application security models do not fully cover.
- The core risk is runtime authority, where an agent can act across systems faster than current governance cycles can review or certify.
- Security teams should build evidence-ready guardrails now so future compliance requirements map onto live controls instead of forcing redesign later.
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, NIST CSF 2.0 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 | The article centers on agentic AI security and runtime governance gaps. | |
| NIST AI RMF | GOVERN | Policy and accountability are central to the article’s regulatory framing. |
| NIST CSF 2.0 | GV.PO-1 | The piece is about policy shaping and governance readiness for AI risk. |
| NIST Zero Trust (SP 800-207) | Agent behaviour needs continuous verification across access and execution. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | AI agents are non-human identities and inherit NHI governance requirements. |
Translate AI policy signals into governance objectives, ownership, and measurable security outcomes.
Key terms
- Agentic AI identity: An identity assigned to an AI system that can take actions in a live environment, not just generate outputs. In governance terms, the identity must be constrained by runtime controls because the system may select tools, combine actions, and affect downstream systems without a human approval gate.
- Runtime authority: The effective permission an actor has while it is executing, including what it can call, change, or delegate in the moment. For AI agents, runtime authority matters more than static entitlement because the security risk is created by behaviour during execution, not only by who authenticated the system.
- Control-plane gap: A mismatch between where a system can act and where security controls are able to observe, approve, or stop it. In agentic AI, this gap appears when DLP, model security, and application security each see part of the action but none can govern the whole chain.
What to expect at the briefing
Zenity's full event covers the operational detail this post intentionally leaves for the source:
- Live discussion of why regulatory bodies are focusing specifically on agentic AI security.
- Practical breakdown of how federal AI risk priorities translate into enterprise governance decisions.
- Panel discussion on where existing regulations leave gaps around AI agents and compliance preparation.
- Interactive discussion of how frontier model partnerships may affect deployment and oversight.
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 building or maturing an identity security programme, it is worth exploring.
Published by the NHIMG editorial team on 2026-07-08.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org