Archetype-aware AI security is now the real governance problem

At a glance

What this is: This is an analysis of why enterprise AI security must be segmented by deployment archetype, with the core finding that controls do not transfer cleanly across embedded, low-code, homegrown, endpoint, and model-based AI.

Why it matters: It matters because IAM, PAM, data, and cloud teams will miss material exposure if they govern AI as a single class, especially where autonomous actions, delegated access, and hidden runtime behaviour change the identity risk model.

👉 Read Zenity's analysis of archetype-aware enterprise AI security

Context

Enterprise AI security fails when the programme treats every AI deployment as the same thing. In practice, the identity and governance problem changes depending on whether the subject is an embedded copilot, a citizen-built agent, a homegrown orchestration pipeline, a coding agent on an endpoint, or a fine-tuned internal model.

Zenity's framing is useful because it shifts the discussion away from tool coverage and toward control fit. For IAM and NHI teams, the central question is not whether AI is present, but which archetype is acting, what identity it uses, and which runtime decisions it is trusted to make.

That distinction is already familiar in identity governance. Human users, service accounts, and autonomous systems do not fail in the same way, so their controls should not be assumed to transfer. The starting point is archetype inventory, because unknown deployment patterns create unknown identity exposure.

Key questions

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. That means defining the runtime permissions, the tools it may invoke, the data it may touch, and the conditions under which a human can still stop or constrain the action. If behaviour can change after approval, build-time review is not enough.

Q: Why do AI security controls often fail to transfer across deployment models?

A: Because the trust boundary changes with the archetype. An embedded copilot, a citizen-built agent, a local coding assistant, and a fine-tuned model each expose different data paths, permissions, and runtime actions. A control that limits prompt leakage in one model may do nothing for tool abuse or endpoint exfiltration in another.

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. That creates a false sense of control because identity, cloud, data, and endpoint layers are only inputs. Real governance requires knowing which systems can act, what they can access, and whether their behaviour stays inside intended bounds.

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.

Technical breakdown

AI deployment archetypes and why control transfer fails

Enterprise AI security becomes a governance problem when security teams assume a single control set can cover every deployment pattern. Embedded SaaS copilots, low-code citizen agents, engineering-built pipelines, endpoint coding agents, and fine-tuned models all sit at different points in the trust chain. Each one consumes different inputs, acts through different permissions, and produces a different blast radius if compromised. Identity, data, cloud, endpoint, and network controls are all context inputs, but none of them are the enforcement point by themselves. The enforcement point is the agent or model acting at runtime, which is why coverage built for one archetype often leaves another effectively ungoverned.

Practical implication: Map controls to each archetype separately instead of assuming a shared AI security baseline will hold.

Runtime enforcement is the real security boundary

The article's strongest technical point is that the decisive risk is not model existence, but runtime action. A system may be approved, monitored, and logged, yet still be unsafe if it can read sensitive data, call APIs, or execute workflows beyond intended bounds. That is why the author separates governance from surrounding infrastructure. DLP, SIEM, cloud posture, and endpoint tooling provide signals, but they do not define what the agent is allowed to do in the moment. For homegrown pipelines and device-based agents, this becomes sharper because tool calls, MCP connections, retrieved context, and inter-agent traffic can all influence action after approval.

Practical implication: Treat runtime decision boundaries as a control requirement, not a monitoring enhancement.

MCP, endpoint AI, and the hidden extension of identity scope

Device-based AI systems create a particularly difficult identity problem because local coding agents and AI tools can extend enterprise reach without central visibility. When an endpoint agent can connect to MCP servers, pull code or context from local resources, and interact with internal services, the effective identity scope expands well beyond the original application boundary. That makes credential handling, tool authorization, and environment trust inseparable. The same logic applies to homegrown pipelines using AI SDKs and orchestration frameworks: each dependency widens the attack surface, and each tool invocation becomes part of the security boundary. Traditional network-centric thinking is too slow for this layer.

Practical implication: Inventory local AI tools and MCP-connected services as part of identity scope, not just endpoint inventory.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Runtime behaviour, not model approval, is the security object. Many programmes still treat AI as if approval at build time were the same as governance at runtime. That assumption breaks as soon as an agent can retrieve context, select tools, and act on enterprise data after the review has ended. The implication is that governance models built around static configuration are incomplete unless they account for the moment of action.

Endpoint AI creates identity blast radius that most IAM programmes still undercount. Device-based coding agents and personal AI tools extend enterprise access through local execution, connected services, and hidden toolchains. This is not just an endpoint problem or just an AI problem. It is a delegated identity problem that crosses user, device, and application boundaries, so practitioners need a clearer view of what can act from the endpoint and under whose authority.

AI security programmes should be organised around control fit, not control reuse. The article's real contribution is the reminder that the same control name can mean something different across archetypes. Identity, data, cloud, endpoint, and network controls each provide part of the picture, but no single layer defines safe behaviour. Teams should therefore align governance, logging, runtime authorization, and dependency review to the archetype in question, not to an abstract AI category.

Archetype inventory is the prerequisite for any credible AI governance model. If an enterprise cannot name which systems are embedded, democratized, homegrown, endpoint-based, or fine-tuned, it cannot credibly assert coverage. That is the operating model gap this article exposes, and it is the point where many AI security discussions fail to become measurable programme work.

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.
• 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.
• That visibility gap connects directly to the control question in OWASP NHI Top 10, where runtime authorisation and delegated access become the decisive risks for agentic systems.

What this signals

Archetype inventory will become a board-level control question, not just an AI architecture exercise. As enterprises spread AI across SaaS copilots, local agents, and engineering pipelines, security leaders will be asked which archetypes are in production, which ones are governed, and which ones remain shadow AI. The practical shift is toward control evidence by deployment pattern, not generic AI coverage claims.

Runtime permissioning will overtake model approval as the higher-value assurance signal. The market is moving toward controls that can explain what an AI system can do after it is deployed, especially where tools, APIs, and local services expand the action surface. That makes identity-centric governance more important than model-centric reassurance, particularly for systems that can act across user, device, and application boundaries.

Identity blast radius is the right name for the emerging problem. When AI tools can execute from endpoints, connect to internal services, and inherit delegated access, the exposure is no longer limited to the model itself. The programme question becomes how far one deployment can reach before governance breaks down, and that is where IAM, PAM, and AI security need a shared operating model.

For practitioners

• 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. Use that inventory to identify which identity owners, data owners, and security teams are accountable for each deployment pattern.
• Map controls to runtime authority, not just platform coverage For each archetype, document what the system can read, call, change, or trigger after approval. Pay special attention to delegated permissions, tool use, and whether a human can still intervene before the action completes.
• 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. If they can reach internal services or code repositories, they belong in the identity scope, not only the device scope.
• Separate build-time approval from runtime containment Require distinct controls for model or workflow approval, then for live behavioural monitoring and action limits. A deployment can be approved and still exceed its intended bounds once it starts selecting tools or consuming external context.
• Use archetype-specific red teaming Test embedded copilots for prompt and output exposure, low-code agents for over-privilege, homegrown pipelines for dependency and inter-agent risk, and endpoint agents for local exfiltration and lateral movement paths. One generic AI test plan will miss these differences.

Key takeaways

• Enterprise AI security fails when teams treat all AI deployments as one category, because each archetype creates a different trust boundary and runtime risk.
• The main governance gap is not tool adoption but runtime authority, since the agent decides what to access and do after approval.
• Practitioners need archetype-specific inventories, controls, and assurance signals if they want AI governance that survives real deployment variety.

Key terms

• AI deployment archetype: A deployment archetype is a distinct pattern of how AI is built, hosted, and allowed to act inside the enterprise. It matters because the same model can present different identity and governance risks depending on whether it is embedded in SaaS, built by users, or run locally on endpoints.
• Runtime authority: Runtime authority is the permission an AI system has while it is actively deciding and acting, not just when it is approved. In governance terms, it is the point where access, tool use, and action scope become operational, which is why build-time review alone cannot prove safety.
• Identity blast radius: Identity blast radius is the amount of enterprise access, data, and downstream action a non-human or autonomous system can reach if it behaves unexpectedly or is compromised. The concept helps teams measure how far one identity can move across systems before containment fails.
• Shadow AI: Shadow AI is AI usage that exists outside approved inventory or governance, including local tools, undeclared agents, and unreviewed workflows. It is dangerous because security teams cannot enforce access, logging, or lifecycle controls on what they cannot see.

Deepen your knowledge

AI archetypes, runtime authority, and delegated access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme that must cover agents, copilots, and machine identities together, it is worth exploring.

This post draws on content published by Zenity: AI Risk Is Not Uniform: The Case for Archetype-Aware Enterprise Security. Read the original.