Skip to content
Paul Marinos
Menu

Frameworks

Zero Trust as an architecture rather than a product, Zero Knowledge as privacy-preserving proof, and Zero Knowledge Trust — the unsolved problem of identity for autonomous AI agents.

Three framings sit under the “zero” banner, they are routinely blurred together, and the third one is barely built yet. This is the material the rest of the site points at as the newest and most distinctive — where identity stops being about humans and their workloads and starts being about autonomous actors that decide and act on their own.

Zero Trust — an architecture, not a product

Section titled “Zero Trust — an architecture, not a product”

Zero Trust is the most oversold term in security, because vendors sell products named after it. The actual idea, from NIST SP 800-207, is simpler and harder: never trust based on network location; verify every request explicitly, continuously, against identity and context.

The mechanics that matter:

  • Policy Decision Point (PDP) and Policy Enforcement Point (PEP). Every access request hits an enforcement point that asks a decision point “should this be allowed, right now, given who and what and where.” The decision is per-request, not per-session, and re-evaluated as context changes.
  • Identity is the perimeter. With no trusted network, the authorization decision moves entirely into identity and device posture. This is why Conditional Access and its equivalents are where Zero Trust actually lives.
  • Microsegmentation limits lateral movement, so a compromise is contained rather than free to roam — the network half of the same principle.

The honest failure mode: Zero Trust as a purchase. You cannot buy it; it’s an architecture you migrate toward, and the CISA Zero Trust Maturity Model is useful precisely because it frames it as a gradient across identity, devices, networks, applications and data rather than a box to check. Most “Zero Trust” that fails, fails because someone bought a product and declared victory.

Zero Knowledge — proving without revealing

Section titled “Zero Knowledge — proving without revealing”

A different idea entirely, and worth separating cleanly. Zero-knowledge proofs let one party prove a statement is true without revealing anything beyond its truth. Prove you know a password without sending it; prove you’re over 18 without revealing your birthdate; prove a transaction is valid without exposing its contents.

Where it touches identity:

  • ZK-based authentication — proving possession of a credential without transmitting it, so there’s nothing to intercept or replay.
  • Password-authenticated key exchange (PAKE) — establishing a mutually authenticated session from a password without the password ever crossing the wire, defeating both interception and server-side password compromise.
  • Privacy-preserving verification — proving an attribute (age, membership, clearance) without disclosing the underlying data, which is data minimization at the protocol level.

This is more mature in cryptography and blockchain than in mainstream enterprise IAM, but the privacy pressure from regulation is pushing it toward relevance — the ability to verify without collecting is exactly what privacy engineering wants.

Zero Knowledge Trust — identity for autonomous agents

Section titled “Zero Knowledge Trust — identity for autonomous agents”

This is the newest and least-solved material on the site, and the reason the whole agentic identity thread exists. As AI systems gain the ability to act — call tools, make purchases, modify systems, invoke other agents — they become a new class of actor that existing identity models were never designed for.

The core problem in one sentence: an autonomous agent is a principal that decides for itself what to do, so granting it authority is not like granting a user access or a service account permissions — it’s delegating judgment. Every hard question follows from that.

  • Delegated authority and scoping. A user tells an agent “book my travel.” The agent now needs authority to spend money, but bounded — this trip, this budget, these vendors. Encoding “what I meant” rather than “what I said” as an enforceable scope is unsolved in the general case, and it’s the whole game.
  • On-behalf-of flows. The agent acts as the user, but is not the user. When it books the flight, who authorized it — the user, or the agent interpreting the user? The audit trail has to capture both, or accountability collapses into “the AI did it.”
  • Credential lifecycle for non-human actors. Agents spin up, spawn sub-agents, and terminate at machine speed and scale. Human credential lifecycle — provision, review, revoke — assumes human timescales and human numbers. Neither holds.
  • Revocation and containment. A compromised or misbehaving agent needs to be stopped mid-action, and it may have already delegated to others. Revocation has to propagate through a tree of delegations faster than the tree can act — a containment problem with no mature answer.
  • Audit trails for agent decisions. Not just what was done, but what the agent was trying to achieve and what it was authorized to attempt. Reconstructing an agent’s intent after the fact is a forensics problem that barely has tooling yet.

The framing that ties it together, and the one worth carrying away: an agent with tools is a confused-deputy problem with a natural-language interface and its own initiative. The classic confused deputy is a program tricked into misusing its authority. An agent is that, except it chooses what to do with its authority, and prompt injection is the mechanism for hijacking that choice. So the security question is not “what can it be tricked into saying” but “what is it authorized to do, and how tightly is that scoped, and can we pull it back” — which is an IAM question wearing an AI hat.

This is where IAM and AI engineering become the same problem viewed from two sides, and it’s genuinely unsolved — which is what makes it worth building expertise in now, ahead of the tooling.

Comparing the frameworks — where each fails

Section titled “Comparing the frameworks — where each fails”
  • Zero Trust fails as a product purchase and succeeds as a slow architectural migration. The maturity-model framing is what keeps it honest.
  • Zero Knowledge is cryptographically strong and operationally immature outside its niches; its enterprise relevance is arriving via privacy regulation rather than security demand.
  • Zero Knowledge Trust for agents is the frontier — the models don’t fully exist, the standards are forming, and the systems shipping agents today are mostly solving it ad hoc, badly, one integration at a time. That gap is the opportunity.

This subsection is the hinge between IAM and AI & Automation — agent identity is the same problem as tool-use authorization and blast radius seen from the identity side. Zero Trust enforcement is Conditional Access and the architecture that implements it. Zero Knowledge’s verify-without- collecting is privacy engineering. And auditing what an agent actually did is a detection and forensics problem we don’t yet have the tools for.

Graph View