Agentic AI Security, Part 2: Identity, Least Privilege, and Zero Trust

Modules 4–6 cover scoped identities for agents and tools, zero-trust networking and policy basics, and advanced patterns (Vault, HSMs, provenance) that matter when LLMs orchestrate sensitive APIs. Consolidated here with links to each canonical module.

Principle of Least Privilege: Scoped Identities and Limiting Blast Radius

Original module on ClawQL Docs: Principle of Least Privilege: Scoped Identities and Limiting Blast Radius.

Even with perfect supply chain security and admission control, a compromised workload or agent can still cause significant damage if it has excessive permissions. The Principle of Least Privilege (PoLP) ensures every identity — human, service, or agent — can do only what is strictly necessary, and nothing more.

This module shows how to implement least privilege across Kubernetes, MCP tools, and agent sessions to minimize blast radius.

Least Privilege in Theory and Practice

Least privilege means granting the minimum permissions required for a task and only for the duration needed. In agentic systems this is critical because agents can chain tools in unexpected ways.Apply least privilege at multiple layers:Kubernetes workloads Human operators Agent/MCP tool calls Session-scoped claims

Per-Workload Identities with Kubernetes RBAC and ServiceAccounts

Every component should run with its own dedicated ServiceAccount and tightly scoped Role/RoleBinding.

Example for the API gateway:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: clawql-api
  namespace: clawql
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: clawql-api-role
rules:
  - apiGroups: [""]
    resources: ["configmaps", "secrets"]
    verbs: ["get", "list", "watch"] # no create/update/delete
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list"] # read-only for status

No production pod should run with cluster-admin or overly broad permissions. Your GitOps or operator pattern should manage these bindings declaratively.

YubiKey Requirement for High-Impact Changes

Any change to production Helm charts for the control plane or critical CRDs requires hardware-backed Git signing with a YubiKey.This ensures that even if a developer workstation is compromised, an attacker cannot push malicious chart changes without physical hardware access. Treat production Helm upgrades as signed, reviewed changes.

Explicit MCP Tool Scoping and ATR Claims

One of the most powerful least-privilege controls in agent stacks is ATR (Agent Task Request) scoping at the MCP layer. Every tool call is validated against the user’s session claims. Agents can only invoke tools explicitly allowed for their role and vertical.

Example ATR-bound tool registration:

Mortgage underwriters can call lending-specific tools but not blockchain or healthcare tools. Sandbox execution is restricted to approved Kata-isolated namespaces. Cross-vertical memory recall requires elevated memory.cross_vertical: true claim.

A synchronous MCP gateway or policy proxy can enforce these scopes synchronously on every clawql_execute call.

Limiting Blast Radius

Combining these controls means that:A compromised pod cannot reach most cluster resources. A compromised agent cannot call dangerous tools. A compromised developer cannot deploy malicious changes without hardware keys. Even full container escape is contained by Kata sandboxing (covered in Module 8).

Key Takeaways

Least privilege turns potential catastrophic breaches into limited incidents. Dedicated ServiceAccounts, narrow RBAC roles, and hardware-backed changes form the foundation. ATR scoping at the MCP gateway provides fine-grained, per-task control that traditional RBAC cannot achieve alone. Every identity and every tool must be explicitly authorized — implicit access is forbidden.

Strong least privilege is the bedrock of zero trust, which is covered next.

Next module: Zero Trust Fundamentals – Assume Compromise and Verify Everything.

Further reading (vendor-neutral)

These resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.

Zero Trust Fundamentals: Assume Compromise and Verify Everything

Original module on ClawQL Docs: Zero Trust Fundamentals: Assume Compromise and Verify Everything.

With supply chain security, golden images, admission control, and least privilege in place, organizations typically shift to a full Zero Trust posture. This module introduces the core philosophy that underpins resilient architectures: never trust, always verify, and assume breach at all times.

Zero Trust Defined for Agentic Systems

Traditional perimeter security (firewalls, VPNs, “inside the cluster is safe”) fails in agentic MCP environments. Agents can call tools, process documents, and interact with external systems in unpredictable ways. Once any component is compromised, lateral movement can be rapid.

A Zero Trust model for agentic systems treats every request, every pod, every agent session, and every tool call as potentially malicious until proven otherwise.

The Three Governing Principles

This module is built on these explicit principles from the Defense-in-Depth guide:Secure the capabilities, not the language
Prompt injection and clever jailbreaks are inevitable. Instead of trying to filter natural language, effective platforms restrict what an agent can actually do through ATR-scoped MCP tools and Panguard enforcement. Every trust assumption is explicit and verified
No implicit trust in containers, model weights, sessions, secrets, or logs. Everything carries cryptographic provenance (Cosign signatures, Merkle roots, JWT ATR claims). Containment over prevention
Assume breach will happen. Design so that when it does, damage is limited, forensic evidence is preserved (WORM + Merkle), and recovery is fast.

Core Zero Trust controls to implement

Continuous verification: Every MCP tool call validates JWT ATR claims, every image is verified at admission, every model weight is checked before inference. Least privilege by default: Covered in Module 4 — narrow RBAC, scoped ServiceAccounts, and per-task tool authorization. Micro-segmentation: Istio mTLS + AuthorizationPolicy (Module 7) ensures pods can only talk to explicitly allowed services. Default-deny posture: NetworkPolicy, egress allowlists, and Kyverno policies reject anything not explicitly permitted. Assume breach mindset: Kata Containers for MCP workloads, automated quarantine with Talon, tamper-evident WORM logs.

Shift from Prevention to Containment

Traditional security focuses heavily on blocking attacks. Well-designed platforms invest equally in containment and recovery:If a pod is compromised → Kata isolation + Talon auto-quarantine. If an agent goes rogue → Panguard blocks the tool call and logs the full session. If logs are tampered → Merkle roots and WORM storage make it detectable.

This mindset changes how you design, deploy, and operate the platform.

Key Takeaways

Zero Trust is not a tool — it is an operating philosophy: assume compromise and verify everything, every time. In agentic systems, securing capabilities through ATR scoping and MCP proxy enforcement is far more effective than trying to secure natural language. Every layer (supply chain, admission, identity, network, runtime) must independently verify and contain. Prevention alone is insufficient; strong containment and forensic readiness are mandatory.

This module sets the stage for the advanced Zero Trust controls in the next module.

Next module: Advanced Zero Trust – Multi-Sig Vault, HSM, Tamper-Proof Logging, and Cryptographic Provenance.

Further reading (vendor-neutral)

These resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.

Advanced Zero Trust: Multi-Sig Vault, HSM, Tamper-Proof Logging, and Cryptographic Provenance

Original module on ClawQL Docs: Advanced Zero Trust: Multi-Sig Vault, HSM, Tamper-Proof Logging, and Cryptographic Provenance.

Building on Zero Trust fundamentals (Module 5), this module covers the advanced cryptographic and secret-management controls that make trust assumptions explicit and verifiable across the entire platform.

Dynamic Secrets with Short TTL

Teams often use HashiCorp Vault for all secrets (database credentials, API keys, mTLS certificates, etc.).Key practices:Secrets are issued dynamically per workload with short TTLs (minutes to hours). Automatic revocation on pod termination. No long-lived static secrets anywhere in the cluster.

Vault Agent sidecars handle token renewal and secret injection. The Operator monitors lease counts and alerts on orphaned credentials.

JWT ATR Session Tokens

Every agent session receives a short-lived JWT containing ATR (Agent Task Request) claims. These claims define exactly what tools, verticals, and data the agent may access.Panguard and the intelligent MCP gateway validate the JWT signature and claims on every clawql_execute call. Agents cannot escalate their own privileges or forge claims.

Merkle Trees and Cryptographic Provenance

Every critical artifact carries tamper-evident provenance:Documents after Presidio redaction Memory 2.0 graph entities and edges Workflow definitions Proxy dispatches and tool call results

A Merkle root is computed and recorded for each operation. Roots are stored in WORM volumes and a Git-backed, Cosign-signed repository. Any silent modification is immediately detectable on read.

WORM Storage and Tamper-Proof Logging

All security-relevant logs (prompts, tool calls, decisions) are written to WORM (Write Once, Read Many) storage.Presidio redaction runs in the Fluent Bit pipeline before logs reach Loki. Merkle roots link logs to the broader audit trail. No deletions or modifications are possible after write.

This ensures forensic integrity even if an attacker reaches the logging infrastructure.

Cosign Blob Signing for Model Weights

Model weights (the largest unverified artifact in most AI stacks) are protected with:Signed manifests stored in Harbor Init-container verification before inference starts SHA-256 hash checking combined with Cosign verification

This closes the “model-in-the-middle” attack vector that container image scanning cannot detect.

Key Takeaways

Dynamic secrets with short TTLs and automatic revocation eliminate standing credentials. JWT ATR tokens enforce explicit, verifiable capabilities at the MCP layer. Merkle trees and WORM storage provide cryptographic proof that nothing has been silently altered. Every trust assumption — from model weights to audit logs — is made explicit and independently verifiable.

These advanced controls turn Zero Trust from a philosophy into enforceable, auditable reality across the platform.

Next module: RBAC, mTLS, and Istio Service Mesh – Network-Level Zero Trust.

Further reading (vendor-neutral)

These resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.

Canonical curriculum and module-by-module versions: Agentic AI Security Curriculum (ClawQL Docs)

Related links