TL;DR: AI agent security is now being shaped by public research, standards work, open-source tooling, and practitioner community building, according to Zenity Labs, with contributions to MITRE ATLAS, OWASP projects, and NIST policy discussions. The central issue is no longer awareness but whether identity and authorization models can keep pace with agentic behaviour.
At a glance
What this is: Zenity Labs describes its research, standards, open-source, and community work as a coordinated effort to advance AI agent security.
Why it matters: It matters because IAM, NHI, and security architecture teams are being pushed to govern autonomous software behaviour, not just static credentials and traditional app access.
By the numbers:
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
👉 Read Zenity's analysis of its AI agent security research, standards, and community work
Context
AI agent security is moving from theory to programme design, and the governance gap is that most identity controls were built for predictable access patterns, not runtime decision-making. In practice, teams are now trying to apply IAM, NHI, and policy frameworks to software that can select actions and tools in the middle of execution. That is why the primary keyword here is AI agent security, not generic AI risk.
Zenity Labs is positioning its work around the parts of the problem practitioners now have to solve: research, standards, open tooling, and community practice. The broader lesson for security teams is that agentic systems need identity and authorization models that are understood by defenders, not just by product builders. For teams already using OWASP NHI Top 10 and related guidance, this is an extension of the same governance problem into autonomous behaviour.
Key questions
Q: How should security teams govern AI agents that can call tools and take actions on their own?
A: Security teams should govern autonomous agents as identity-bearing actors, not as ordinary applications. That means defining ownership, limiting tool scope, logging runtime decisions, and reviewing delegation paths across the lifecycle. The critical difference is that access must be constrained at the moment of action, not only at provisioning time.
Q: Why do AI agents create new IAM and NHI governance problems?
A: AI agents create new governance problems because they can move from request to execution without the fixed patterns that traditional IAM assumes. Their permissions may be valid, but their action sequence can still be unexpected. That makes runtime visibility, policy scope, and accountability harder to maintain than with static service accounts or human users.
Q: What do security teams get wrong about AI agent risk management?
A: Teams often treat agent risk as a tooling issue when it is really a governance issue. The mistake is assuming that access review, policy, or prompt filtering alone will cover autonomous behaviour. In practice, organisations need clear ownership, lifecycle controls, and a way to distinguish allowed tasks from allowed outcomes.
Q: Who should be accountable when an AI agent behaves outside policy?
A: Accountability should sit with the team that owns the agent, its permissions, and the business process it supports. If an autonomous system can act without approval, governance must define who reviews its scope, who can suspend it, and who signs off on its offboarding. Without that clarity, incidents become ownership disputes.
Technical breakdown
AI agent security research as attack-surface discovery
Security research in AI agent security is not just about finding bugs. It is about mapping the attack surface created when software can reason, call tools, and chain actions across systems. That changes the defender's job from protecting a single application boundary to tracing how agent permissions, memory, tools, and external connectors combine into a usable path for abuse. Public disclosure matters because it turns hidden failure modes into shared control requirements. The same logic now applies across NHI and agentic AI programmes: if an identity can act, it must also be governable.
Practical implication: treat agentic behaviour as an identity and authorization problem, not only an application-security problem.
Standards bodies are becoming part of the control plane
When AI security teams contribute to OWASP, MITRE ATLAS, and NIST discussions, they are helping define the vocabulary that controls will later use. That matters because AI agent security depends on shared definitions for tool misuse, delegation, authorization scope, and runtime decision authority. Standards do not remove risk, but they make it easier to compare controls, write policy, and align procurement requirements. Without that layer, every organisation invents its own model and ends up with inconsistent boundaries for agents, workloads, and human oversight.
Practical implication: align internal agent governance language to emerging standards before control requirements become fragmented across teams.
Open source is accelerating AI agent attack-surface visibility
Open-source tooling in this space is valuable because it lets defenders inspect how agent paths are discovered, tested, and abused. That is especially important where agentic systems sit on top of APIs, workflow engines, and secrets stores. The technical issue is not whether the tool is open source in the abstract. It is whether security teams can reproduce the same discovery logic internally and apply it to their own agent estate. AI agent security becomes materially harder when visibility depends on vendor claims rather than inspectable methods.
Practical implication: prefer inspectable testing and mapping methods for agents, then validate them against your own environment.
NHI Mgmt Group analysis
AI agent security is becoming an identity governance discipline, not a niche AI issue. Zenity Labs' research, standards, and community model shows that the field is converging on governance, not just detection. Once agents can select tools and initiate actions, the question becomes who can authorize, review, and constrain those actions across the lifecycle. Practitioners should treat this as a cross-programme identity problem spanning NHI, IAM, and emerging agentic controls.
Standards participation is now part of the security control stack. Zenity Labs' focus on OWASP, MITRE ATLAS, and NIST reflects a broader market shift: the language of control is being written in public before products fully mature. That matters because agent governance without shared standards becomes inconsistent and hard to audit. The implication is that security teams will increasingly be judged by how quickly they can map internal policy to emerging external frameworks.
Open-source research is exposing the gap between visibility and governance. Public tools and disclosures are making AI agent attack paths easier to see, but visibility alone does not equal control. The market is moving toward environments where defenders can inspect agent behaviour yet still lack the policy, ownership, and review mechanisms to govern it consistently. Practitioner teams should assume the visibility gap is closing faster than the governance gap.
Agent control standardisation: the next governance battleground is not whether agents exist, but whether their actions can be described, reviewed, and restricted in a common control language. Zenity Labs' work points to a field that is trying to standardise the semantics of agent identity before the operational patterns harden. That is the right direction because without a shared vocabulary, enterprises will keep building incompatible controls around the same behaviour. Practitioners should expect procurement, audit, and architecture decisions to increasingly hinge on this standardisation layer.
Community-led research is now a resilience mechanism. The 0-dAI model signals that AI agent security knowledge is no longer flowing only through vendors and closed labs. When practitioners, researchers, and policymakers share attack patterns early, control quality improves faster than private reporting models allow. The implication is clear: organisations that stay outside these communities will learn slower and govern later.
From our research:
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including unauthorised system access, sensitive data sharing, and revealing credentials.
- For the governance lens behind this shift, see OWASP Agentic AI Top 10 for the controls most likely to matter next.
What this signals
With 80% of organisations already reporting agent actions beyond intended scope, the governance problem is no longer theoretical. Security programmes need to move from proof-of-concept oversight to continuous control of tool use, delegation, and offboarding across the agent lifecycle.
Agent control standardisation: the organisations that will scale AI safely are the ones that can express agent permissions, approval boundaries, and review expectations in a shared control language. That is why work aligned to the OWASP Agentic AI Top 10 and MITRE ATLAS matters now, before fragmented local policies become the default.
In practice, the programme signal to watch is whether agent behaviour can be traced back to a named owner, a current purpose, and a reviewable policy set. If not, the organisation has visibility without governance, which is the most common failure pattern in early AI agent deployments.
For practitioners
- Map agent decision authority separately from application access Document which agents can choose tools, trigger actions, and chain steps without human approval. Use that map to distinguish normal workload access from runtime autonomy and to identify where governance should move from static entitlements to behavioural controls.
- Align internal policy to external agent security standards Crosswalk your current controls to the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework, then record where agent-specific requirements are still missing. This makes it easier to write procurement language, audit expectations, and architecture guardrails in one place.
- Use inspectable research methods for agent attack-surface testing Require repeatable testing for agent prompts, tool use, delegation paths, and connector exposure so security teams can reproduce findings internally. Where possible, pair this with MITRE ATLAS mappings to keep threat modelling and detection work aligned.
- Build a review cadence for agent policies and permissions Set a recurring process to validate whether agent permissions still match current business tasks, especially after tool additions or workflow changes. This should include ownership, escalation rules, and offboarding steps for agents that are retired or replaced.
Key takeaways
- Zenity Labs' work shows that AI agent security is maturing into a governance and standards discipline, not just a research niche.
- The most useful signal in the broader market is that visibility is improving faster than control, which leaves identity teams with a widening policy gap.
- Practitioners should align agent controls, standards mapping, and lifecycle ownership now, because unmanaged autonomy becomes harder to correct after deployment.
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 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agent tool use and runtime action paths are central to the article. | |
| NIST AI RMF | The article focuses on AI governance, standards, and accountability. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Agent identities need lifecycle and privilege governance like other non-human identities. |
Map agent workflows to OWASP agentic controls and require reviewable boundaries for tool use.
Key terms
- Agentic AI Security: The practice of governing AI systems that can choose actions, call tools, and execute steps at runtime. It extends identity and access thinking into autonomous behaviour, so security teams must control not only who or what the system is, but what it is allowed to decide and do.
- Agent Attack Surface: The set of paths through which an AI agent can be influenced, misused, or abused through prompts, tools, connectors, memory, and delegation. It is broader than application attack surface because the agent's runtime choices can turn a valid permission into an unintended action.
- Agent Governance: The policies, ownership, review, and accountability mechanisms used to control AI agents across their lifecycle. In practice, it means assigning responsibility for permissions, decision scope, escalation, and offboarding so autonomous behaviour stays inside an auditable boundary.
Deepen your knowledge
NHI governance, agentic AI identity, machine identity security, IAM, and identity lifecycle management 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 NHI governance in your organisation, it is worth exploring.
This post draws on content published by Zenity: Zenity Labs: The Bleeding Edge. Read the original.
Published by the NHIMG editorial team on 2026-06-08.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org