Notifications
Clear all
Topic starter
04/06/2026 2:58 pm
TL;DR: Enterprise AI security breaks down when teams treat all deployments as one category, because embedded copilots, low-code agents, engineering pipelines, endpoint coding agents, and fine-tuned models each create different threat models and control requirements, according to Zenity. The decisive gap is structural: the agent is the enforcement point, but most programmes still govern the surrounding infrastructure instead of runtime behaviour.
NHIMG editorial — based on content published by Zenity: AI Risk Is Not Uniform: The Case for Archetype-Aware Enterprise Security
Questions worth separating out
Q: How should security teams govern AI systems that can take actions on their own?
A: They should govern the actor, not just the infrastructure around it.
Q: Why do AI security controls often fail to transfer across deployment models?
A: Because the trust boundary changes with the archetype.
Q: What do organisations get wrong about AI security coverage?
A: They often treat AI as a single category and then count tool coverage as governance.
Practitioner guidance
- Inventory AI by archetype before you assess tools Build a live register that separates embedded SaaS copilots, low-code citizen agents, homegrown pipelines, endpoint coding agents, and fine-tuned models.
- Map controls to runtime authority, not just platform coverage For each archetype, document what the system can read, call, change, or trigger after approval.
- Treat endpoint AI as an identity boundary Include local coding agents, MCP-connected tools, and developer-side AI assistants in access reviews and endpoint governance.
What's in the full article
Zenity's full research covers the operational detail this post intentionally leaves for the source:
- Archetype-by-archetype control breakdowns for embedded, democratized, homegrown, device-based, and fine-tuned AI systems
- Six lifecycle phases mapped to AI security operations from governance and asset identification through detection and response
- Examples of the controls that matter for different AI deployment patterns, including runtime monitoring and dependency validation
- The vendor's recommended way to think about the full AI security landscape across categories and lifecycle stages
👉 Read Zenity's analysis of archetype-aware enterprise AI security →
AI security archetypes: what IAM teams are missing today?
Explore further
04/06/2026 3:10 pm
Archetype-aware governance is now the baseline for enterprise AI security. The article is correct that controls do not transfer cleanly across deployment patterns because each archetype changes the trust boundary, the runtime action model, and the failure mode. A copilot inside SaaS, a no-code agent built by a business user, and a local coding agent on an endpoint all create different identity outcomes. Practitioners should stop asking whether the organisation has AI security and start asking which AI archetypes are actually governed.
A few things that frame the scale:
- 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.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is why hidden access paths remain a governance problem rather than a tooling problem.
A question worth separating out:
Q: How can IAM teams decide which AI deployments need the strictest controls?
A: Start with the archetypes that can act beyond simple text generation, especially low-code agents, homegrown pipelines, and endpoint-based coding tools. Then prioritise the systems that can reach sensitive data, invoke internal APIs, or operate without a clear human checkpoint. Those are the environments where identity risk becomes operational risk.
👉 Read our full editorial: Archetype-aware AI security is now the real governance problem
