TL;DR: Detection, monitoring and protection for AI systems and AI agents are now in a federal procurement channel built for AI, ML, data and analytics capabilities after HiddenLayer says its AI security platform achieved Awardable status in the DoD CDAO’s Tradewinds Solutions Marketplace, and the shift matters because AI security is now being evaluated as an identity and lifecycle governance problem, not just a model-risk issue.
At a glance
What this is: HiddenLayer says its AI security platform is now Awardable in the DoD CDAO’s Tradewinds Solutions Marketplace, signalling that AI systems and AI agents are being treated as procurement-grade security concerns.
Why it matters: For IAM, NHI, and autonomous-system programmes, this matters because AI identity risk is moving into the same governance conversation as workload identity, lifecycle control, and runtime protection.
👉 Read HiddenLayer's news release on Tradewinds Awardable status for AI security
Context
AI security is the discipline of detecting, monitoring, and protecting AI systems from adversarial abuse across their lifecycle. In this case, the governance question is not whether AI exists in the enterprise, but how procurement, security review, and operational controls are catching up to AI agents that can act in production.
HiddenLayer’s Tradewinds status shows how quickly the category is moving from point tooling to approved acquisition paths. For practitioners, that changes the conversation from experimentation to control mapping: what identity model applies, who owns lifecycle governance, and how runtime protection is measured against the actual behaviour of AI agents.
Key questions
Q: How should security teams govern AI agents as non-human identities?
A: Security teams should classify AI agents as non-human identities with explicit ownership, scope, and retirement criteria. That means linking the agent to its tool access, data access, logging, and change control, then reviewing those entitlements on the same lifecycle cadence used for other machine identities. If the agent can act at runtime, identity governance must apply at runtime too.
Q: Why do AI agents change the way IAM programmes think about access control?
A: AI agents change access control because they can combine permissions dynamically while executing a task, which makes static provisioning assumptions weaker. The real issue is not just who approved access, but whether the system can observe and constrain what the agent does after approval. That is why runtime authorisation and telemetry matter more than one-time setup.
Q: What breaks when AI security is treated only as model security?
A: Model-only security misses the part of the system that actually touches tools, data, and workflows in production. A secure model can still produce unsafe outcomes if the surrounding agent, connectors, or permissions are not governed. Practitioners need controls that follow the operational identity, not just the model artefact.
Q: How should organisations decide whether to buy AI security tools through procurement channels?
A: Organisations should buy AI security tools only after mapping them to identity ownership, logging requirements, and lifecycle controls. Procurement should ask who will manage access, who will review agent behaviour, and how the tool fits with existing NHI and zero-trust governance. If those answers are unclear, the purchase creates more risk than clarity.
Technical breakdown
AI security in procurement pipelines
Tradewinds Solutions Marketplace is a federal acquisition channel for AI, ML, data, and analytics capabilities. Awardable status means the solution has passed a competitive review path that makes it easier for government buyers to move from interest to procurement. For identity teams, that matters because security controls for AI now sit inside acquisition decisions, not only deployment decisions. Once AI security is procured through a formal marketplace, governance must cover who approves use, what identities the system consumes, and how lifecycle obligations are recorded when the system is updated or retired.
Practical implication: map AI security tools into procurement and lifecycle controls before they enter production use.
AI agents as non-human identities
The source article treats AI agents as part of the protected surface, which is the correct framing for identity governance. An AI agent is not just a model. It is a runtime actor that may touch tools, data, and execution paths, which makes it behave like a non-human identity even when the underlying infrastructure is ordinary. That shifts attention from static model approval to continuous control of access, scope, and observability. The relevant question is whether the agent’s permissions, logs, and decision boundaries are governed as identity attributes rather than as generic application settings.
Practical implication: classify AI agents in your identity model and govern their access like other non-human actors.
Runtime protection versus model-only security
The article’s emphasis on detection, monitoring, and protection against emerging AI threats reflects a wider control reality. Model-only security focuses on the artefact. Runtime security focuses on what the system does once it is deployed and connected to tools, data, and workflows. That distinction matters because many AI failures happen after deployment, when prompt injection, adversarial inputs, or tool misuse alter behaviour in production. For identity practitioners, runtime protection is where authorisation, telemetry, and containment become more important than one-time model validation.
Practical implication: evaluate AI security controls on runtime behaviour, not just pre-deployment testing.
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
AI security procurement is becoming an identity governance decision. When a federal acquisition channel starts awarding status to AI security platforms, the category is no longer confined to experimentation or research. Procurement now encodes expectations about detection, monitoring, lifecycle support, and operational accountability. That means IAM, NHI, and security architecture teams need common language for who owns the AI identity surface from purchase through retirement.
AI agents should be governed as non-human identities, not as abstract model features. The source article’s treatment of AI agents as a protected target is the right operational lens. An AI agent consumes permissions, tools, and data in ways that create identity behaviour, which makes OWASP-NHI and zero-trust thinking more relevant than model-centric security alone. Practitioners should classify agents by runtime authority, not by vendor label or interface.
Runtime protection is now the control plane that matters most for AI risk. Static approval of a model or platform does not control what happens after the system is connected to production data and tools. HiddenLayer’s positioning reflects a broader market shift toward continuous observation of AI behaviour, which aligns with NIST-CSF and ZT-NIST-207 expectations for ongoing verification. The practitioner conclusion is simple: if you cannot observe and constrain runtime actions, you do not really govern the system.
Tradewinds-style procurement will accelerate category consolidation in AI security. Once acquisition pathways reward solutions that can be bought and deployed quickly, buyers will face stronger pressure to consolidate tooling around governance, detection, and runtime protection. That may simplify purchasing, but it can also mask unresolved identity ownership questions across human operators, service accounts, and AI agents. Teams should re-evaluate where AI security sits relative to existing NHI and PAM controls.
Named concept, AI identity acquisition path: This is the point where identity controls are no longer added after deployment but evaluated as part of the acquisition path itself. The implication is not that security teams need another product category. The implication is that procurement, identity classification, and operational oversight are converging into one governance decision, and teams that still separate them will miss the control gap.
From our research:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
- For the governance model behind that gap, see Top 10 NHI Issues and align AI agent oversight to the same lifecycle discipline.
What this signals
AI security procurement will keep moving closer to identity governance. When buyers can acquire AI security through approved channels, the practical question becomes how quickly their identity model can absorb AI agents, connectors, and runtime controls. Teams that still separate AI governance from NHI governance will struggle to assign ownership cleanly.
1.5 out of 10 organisations are highly confident in securing NHIs, according to our research. That confidence gap is the warning sign for AI agent governance as well, because the same ownership, visibility, and lifecycle problems tend to reappear once autonomous or semi-autonomous systems start consuming access.
Runtime control is the next place programmes will be judged. Discovery and approval are not enough once an AI system can act in production. Teams should prepare for audit questions about logging, revocation, and scope control across both AI agents and the non-human identities they depend on.
For practitioners
- Classify AI agents in your identity inventory Record each agent as a non-human identity with an owner, scope, and retirement path. Tie that record to the systems it can access, the tools it can invoke, and the approvals required to change those rights.
- Review procurement criteria for runtime controls Require evidence of detection, monitoring, and containment before AI security tools are approved for production use. Make sure procurement checks include logging coverage, access boundaries, and lifecycle ownership.
- Map AI agent access to existing NHI governance Align agent permissions with the same review cadence used for other non-human identities. Where the agent can call tools or services, confirm entitlement scope, logging retention, and offboarding triggers.
- Separate model assurance from operational assurance Treat model evaluation as only one part of the control picture. Add runtime validation for tool use, identity propagation, and response containment so that post-deployment behaviour is continuously governed.
Key takeaways
- AI security is now moving through procurement channels that force identity questions into the buying process, not just deployment.
- AI agents should be treated as governed non-human identities because their runtime access, not their model label, creates the security exposure.
- Teams that cannot connect procurement, ownership, and runtime protection will find that AI governance remains incomplete after approval.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while 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 Non-Human Identity Top 10 | NHI-01 | AI agents acting as identities need lifecycle ownership and scoped access. |
| NIST CSF 2.0 | PR.AC-4 | AI runtime access must be limited and reviewed like other privileged access. |
| NIST Zero Trust (SP 800-207) | PR.AC | Continuous verification fits AI systems that change behaviour at runtime. |
Classify AI agents as NHIs and assign owners, boundaries, and offboarding controls.
Key terms
- AI Agent: A software entity that can choose actions, tools, and execution timing during runtime. In identity governance terms, it behaves like a non-human actor that needs ownership, scope, monitoring, and revocation controls, especially when it can affect production systems or data without a human approval step.
- Runtime Protection: Runtime protection is the set of controls that monitor and constrain a system after deployment. For AI, it focuses on live behaviour, tool use, and access boundaries rather than only pre-release testing, because many security failures appear when the system is connected to real data and workflows.
- Non-Human Identity: A non-human identity is any machine or software identity that authenticates and acts in a system, including service accounts, tokens, keys, certificates, bots, and AI agents. The governance challenge is not just issuance, but lifecycle control, visibility, and timely removal when the actor no longer needs access.
Deepen your knowledge
AI agent governance and non-human identity lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending identity governance into AI systems, this is a practical starting point.
This post draws on content published by HiddenLayer: Awardable status for Department of Defense work in the CDAO’s Tradewinds Solutions Marketplace. Read the original.
Published by the NHIMG editorial team on 2026-06-02.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org