The AI-Native Security Stack: Identity, Policy, and Enforcement Layers

Engineering and governance teams often talk past each other on AI security. Engineering ships tool allowlists and hope. Governance publishes acceptable-use policies the runtime never reads. Neither side is wrong about priorities — they lack a shared stack diagram that shows where identity is established, where rules are defined, and where violations are blocked.

This article proposes a three-layer model — identity, policy, enforcement — that maps cleanly to components you can build, audit, and argue about in the same meeting.

Why layers beat a flat control list#

Flat checklists ("enable logging, use a safe model, add human review") hide dependencies. Human review without identity binding approves the wrong user's request. Policy prose without enforcement is theatre. Enforcement without policy definitions becomes hard-coded if statements that nobody can explain to auditors.

Layers make ownership obvious:

1. Identity layer — who and what is acting
2. Policy layer — what is allowed under which conditions
3. Enforcement layer — what actually runs or stops at execution time

Each layer has inputs, outputs, and failure modes. Incidents usually trace to a missing layer or a gap between them — not to "the model misbehaved."

Layer 1: Identity#

Identity answers three distinct questions that AI systems often conflate:

• End-user identity — the human or service account initiating the session
• Agent identity — the software principal executing workflows (may differ from the user)
• Tool credentials — tokens or roles used when calling downstream APIs

In a refund workflow, the user might be a tier-1 support agent, the agent identity might be support-agent-prod, and tool credentials might be scoped to read orders for that agent's tenant only. Mixing these — one super-token for all agents — collapses the layer.

Identity requirements#

• Bind every tool call to (user_id, agent_id, session_id, workflow_id)
• Issue credentials per workflow, not per "AI platform"
• Propagate tenant context from auth gateway through retrieval and tools
• Reject "role claims" originating from model context or retrieved documents

from dataclasses import dataclass

@dataclass(frozen=True)
class AgentIdentity:
    user_id: str
    agent_id: str
    tenant_id: str
    workflow_id: str
    credential_scope: str  # e.g. "support-readonly-v2"

def bind_tool_call(identity: AgentIdentity, tool_name: str) -> dict:
    """Attach identity claims consumed by policy and audit."""
    return {
        "sub": identity.user_id,
        "agent": identity.agent_id,
        "tenant": identity.tenant_id,
        "workflow": identity.workflow_id,
        "scope": identity.credential_scope,
        "tool": tool_name,
    }

If your audit log cannot reconstruct this tuple for a given tool invocation, the identity layer is incomplete.

Layer 2: Policy#

Policy is the declarative layer: rules humans can review without reading application code. It sits between intent (product requirements) and enforcement (code paths). Good policy artifacts are versioned, diffable, and scoped by workflow.

Examples of policy statements:

• create_refund: allowed if amount_cents <= policy.max_refund(order) and user has role support_t2
• send_email: destination domain must be in tenant allowlist
• search_kb: index scope limited to tenant_id from identity layer
• Workflows reading untrusted web content: no write tools

Policy should not live only in system prompts. Prompts express tone and task; policy expresses authorization and business limits in a form enforcement can evaluate.

Policy layer deliverables#

Governance owns the approval process; engineering owns keeping manifests synchronized with deployed runtimes. Drift between manifest and production is a finding, not an inevitability.

Layer 3: Enforcement#

Enforcement is where proposals become outcomes or denials. It runs after the model proposes a tool call (or an action edge case) and before side effects touch production systems.

Enforcement responsibilities:

• Validate tool name against workflow allowlist
• Parse and schema-validate arguments
• Evaluate policy rules with identity claims attached
• Apply rate limits, amount caps, and approval gates
• Emit audit events on allow, deny, and defer-to-human

The model never bypasses this layer. If enforcement is optional on a code path, that path is a vulnerability.

type EnforcementDecision = "allow" | "deny" | "require_approval";

async function enforce(
  proposal: ToolProposal,
  identity: IdentityClaims,
  policy: PolicyManifest
): Promise<EnforcementDecision> {
  if (!policy.toolsForWorkflow(identity.workflow).includes(proposal.name)) {
    return "deny";
  }
  const parsed = parseArgs(proposal.name, proposal.args);
  const rule = policy.ruleFor(proposal.name);
  const result = rule.evaluate(parsed, identity);
  if (result.exceedsAutoApproveThreshold) {
    return "require_approval";
  }
  return result.permitted ? "allow" : "deny";
}

Human approval is a branch of enforcement, not a substitute for policy. Approvers need context: identity tuple, policy rule triggered, and proposal diff — not a chat transcript alone.

How layers connect in a request#

A typical agent request flows:

1. Gateway authenticates user, mints session, selects workflow → establishes identity
2. Orchestrator loads policy manifest for that workflow → policy layer active
3. Model runs with tools filtered to policy-permitted set
4. Model proposes tool call → enforcement evaluates before execution
5. Audit pipeline records identity + policy version + decision + outcome

Breaks happen at handoffs: identity established at gateway but not passed to retrieval (cross-tenant leak); policy updated in Git but not deployed to runtime (ghost rules); enforcement logs denials but nobody alerts (silent abuse attempts).

Anti-patterns that collapse the stack#

• Prompt-only policy — "Never refund more than $50" in prose with no arg check
• Shared agent service account — one identity for billing, support, and internal ops agents
• Enforcement in the model — asking GPT to decide if a refund is fair
• Policy without versioning — incident reconstruction impossible after prompt hotfix
• Identity without retrieval scoping — correct user, wrong tenant's documents

Each anti-pattern removes a layer while leaving the UI unchanged. Demos still look fine.

Operating the stack in production#

On-call should dashboard: deny rate by tool, approval queue depth, policy version skew across pods, spikes in rare-tool success. Change management treats policy manifest updates like API schema changes — with rollback. Onboarding for new agents requires all three layers designed together, not "add tools later."

Security reviews should walk the stack bottom-up: identity diagram, policy manifest excerpt, enforcement code path for the highest-risk tool. Skipping a layer in review predicts which layer fails in prod.

Mapping controls to accountability#

Summary#

AI-native security stacks in three layers: identity establishes who acts, policy declares what is permitted, enforcement blocks or approves before side effects occur. Prompts and model safety sit adjacent to this stack — they do not replace it. Build each layer as an explicit component with versioned artifacts and audit hooks; keep governance documents synchronized with what production enforces.