Subscribe to the Non-Human & AI Identity Journal

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.

Expanded Definition

An AI deployment archetype is the operating pattern that determines where an AI capability lives, who controls it, what data it can reach, and how much execution authority it receives. In NHI governance, the archetype matters as much as the model itself.

Definitions vary across vendors, but the practical distinction is whether AI is embedded in a third-party SaaS feature, exposed through an internal platform, built as a user-facing assistant, or run locally on an endpoint. Each pattern creates a different trust boundary, identity footprint, and blast radius. That is why NIST Cybersecurity Framework 2.0 is useful as a governance lens even though it does not name this term directly: deployment context changes asset management, access control, and monitoring requirements. The same AI model can be low risk in read-only mode and high risk once it can call tools, write files, or issue requests through an NIST Cybersecurity Framework 2.0 aligned control environment.

The most common misapplication is treating all AI deployments as one category, which occurs when teams assess model capability but ignore hosting model, identity propagation, and tool access.

Examples and Use Cases

Implementing AI deployment archetypes rigorously often introduces governance overhead, requiring organisations to weigh faster adoption against stricter review of identity, permissions, and data paths.

  • A SaaS copilot embedded in a business application inherits the provider’s controls, but still needs review for NHI exposure, audit logging, and downstream data sharing.
  • An internal agent built on a platform like MCP may have broad tool access, so the deployment archetype must define whether it can read secrets, trigger workflows, or only suggest actions.
  • An endpoint-based assistant running locally can reduce cloud exposure, yet it often expands the attack surface on user devices and complicates centralized policy enforcement.
  • A customer-facing chatbot may appear low risk until it is allowed to execute tasks, at which point identity boundaries and approval flows must align with NIST Cybersecurity Framework 2.0 monitoring and response expectations.
  • When a deployment exposes credentials or sensitive prompts, the pattern resembles the failure dynamics seen in the DeepSeek breach, where governance gaps became visible through real data loss.

These use cases show why the label should describe operational authority, not just product packaging.

Why It Matters in NHI Security

Deployment archetypes shape how NHI controls are enforced, because the same agent or model can behave as a harmless assistant in one environment and a privileged actor in another. A poorly classified archetype can hide unmanaged secrets, overbroad tokens, and weak approval chains behind what looks like ordinary application traffic.

That is especially important because AI systems can reproduce sensitive patterns once they are trained on exposed code or credentials. In The State of Secrets in AppSec, 43% of security professionals said they are concerned about AI systems learning and reproducing sensitive information patterns from codebases. When deployment archetypes are unclear, that concern becomes operational: logs, prompt stores, vector databases, and tool connectors may all hold secrets in different places with different owners. The DeepSeek breach is a reminder that exposure is often a consequence of architecture plus identity misuse, not model behavior alone.

Organisations typically encounter the consequence only after a prompt leak, unauthorized tool call, or credential exposure, at which point the deployment archetype becomes operationally unavoidable to address.

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 CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Agentic AI Top 10 A1 Agentic AI risk starts with deployment pattern and tool authority.
OWASP Non-Human Identity Top 10 NHI-02 Deployment archetypes often hide secret exposure and overprivileged NHI paths.
NIST CSF 2.0 PR.AC-4 Access control expectations change with the deployment's execution boundary.

Classify each AI deployment by its actions, permissions, and tool reach before enabling autonomy.