Identity · Scope · Integrity

I, Agent Identity-First Security
for the Autonomous Future

What if Asimov wrote the security spec for your AI agent?

Aydrian Howard Senior Developer Advocate · Auth0 / Okta · @itsaydrian

Identity Scope Integrity

Aydrian Howard

Senior Developer Advocate · Auth0

Hoosier living in the big city. Corgi dad. Passionate about education, mentoring at hackathons, and building things live on Twitch.

@itsaydrian linkedin.com/in/aydrian github.com/aydrian itsaydrian.dev

The Original Three Laws

Asimov's Three Laws
of Robotics

1

A robot may not injure a human being or, through inaction, allow a human being to come to harm.

2

A robot must obey orders given it by human beings except where such orders would conflict with the First Law.

3

A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

Asimov was worried about robots harming people. I'm worried about what AI agents will do with your credentials.
Today we rewrite these laws as Identity, Scope, and Integrity.

The Problem

Agents Without Identity

AI agents act — reading email, making purchases, querying private data — but can't prove who they are
Threats: prompt injection, overpowered credentials, anonymous agents with admin keys
Your agent passed all the evals. Its system prompt is locked down. But the identity was never checked

"If identity is compromised,
every other security policy fails."

Law I — Identity

The "Who"

"An agent must always maintain a unique, verifiable identity and must never act anonymously or under a masked provenance."

Not "An AI" — "Assistant0 Instance #452 acting for User Jane"
Require login via OpenID Connect — every session tied to a verifiable subject ID (sub)
Middleware check: if identity is missing or forged, request terminates

🔐

Verified Login

The agent must log in — just like a user does. Every session is tied to a verifiable identity.

🪪

Subject ID (sub)

Immutable proof of identity. Ties every action to a specific user + agent instance.

Law II — Scope

The "What"

"An agent must only perform actions within its explicitly delegated permissions, except where such actions would violate the Law of Identity."

Use a token vault to issue scoped, time-limited access tokens — not broad credentials
Prompt injection tries to delete your Drive? The vault only issued gmail.readonly, not admin
Even if the Brain wants to do it, the Hands can't reach the button

🏦

Token Vault

Issues scoped, time-limited tokens per tool call. The agent never holds broad credentials.

🛡️

API-Layer Defense

Least privilege enforced at the identity layer — not the model layer. Prompt injection can't bypass it.

Law III — Integrity

The "How"

"An agent must protect its own credentials and session tokens, as long as such protection does not conflict with the First or Second Laws."

CIBA (Client-Initiated Backchannel Authentication): human-in-the-loop for high-risk actions
Credentials never leave the vault — the agent never "sees" refresh tokens
An agent protects its integrity by knowing when its authority ends and a human's begins

📱

Human-in-the-Loop Approval

Push notification to the user's device: "Approve this tool call?" Real-time human-in-the-loop.

🔒

Credential Isolation

Refresh tokens stay in a secure vault — never exposed to the agent. Only short-lived access tokens are issued.

The Three Laws of Agentic Identity

I. The Law of Identity

An agent must always maintain a unique, verifiable identity and must never act anonymously or under a masked provenance.

The Foundation: Without a verifiable identity, no other security policy can be trusted.

II. The Law of Scope

An agent must only perform actions within its explicitly delegated permissions, except where such actions would violate the Law of Identity.

The Hierarchy: You cannot grant "permissions" to an entity that hasn't first proven who it is.

III. The Law of Integrity

An agent must protect its own credentials and session tokens, as long as such protection does not conflict with the First or Second Laws.

The Guardrail: An agent shouldn't "hide" its identity or bypass scopes even in the name of "self-preservation" or efficiency.

Identity-First Architecture

Enforcement lives in the identity layer — not in your application code.

🏛️

Apex — Law III: Integrity

CIBA async authorization · Human approval flow · Credential isolation

↑

🔧

Middle — Law II: Scope

Token Vault · Scoped access tokens · Least privilege at the identity layer

↑

🔑

Foundation — Law I: Identity

Verified login (OIDC) · Subject ID (sub) · Identity tokens · Root of trust

Three Laws in One Tool

A single tool definition demonstrating all three laws:

export const sendDraftTool = tool({
  description: 'Drafts an email for the user',
  execute: async (args, { sessionId }) => {

    // LAW 1: IDENTITY — Verify the agent and user context
    const session = await getAuthSession(sessionId);
    if (!session.user) throw new Error("Violation: Law of Identity");

    // LAW 2: SCOPE — Request a scoped token for the task
    const token = await tokenVault.getToken({
      provider: 'google',
      scopes: ['googleapis.com/auth/gmail.compose']
    });

    // LAW 3: INTEGRITY — High-risk triggers approval
    if (isHighRisk(args)) {
      return await initiateAsyncApproval({
        userId: session.user.id,
        message: "Approve drafting this email?"
      });
    }
    return await gmailClient.draft(args, token);
  },
});

Live Demo

Assistant0

All Three Laws in Action

Identity Scope Integrity

TypeScript · Vercel AI SDK · Auth0 for AI Agents

Demo — Law I

Identity Check

Live Demo

The auth0 middleware gates every request. No valid session = redirect to login.

// Middleware: identity gate
const session = await auth0.getSession(request);

if (!session) {
  return NextResponse.redirect(`${origin}/auth/login`);
}
// session.user.sub → verified identity

What to watch for

Login screen (powered by Auth0)
Session tied to specific sub
Unauthenticated requests rejected

Demo — Law II

Scope Enforcement

Live Demo

"What are my most recent emails about AI?"

The withGmailRead wrapper binds a scoped token to the tool — the agent can read, but cannot send or delete.

// Scoped token via Token Vault
export const gmailSearchTool = withGmailRead(
  tool({
    description: 'Search Gmail messages',
    execute: async ({ query }) => {
      const token = await getReadAccessToken();
      // token scoped to gmail.readonly
      // ✗ Cannot send, delete, or admin
    },
  }),
);

Prompt injection defense

LLM tricked into "delete all Drive files"
Token Vault only issued gmail.readonly
API rejects — scope stops it

Demo — Law III

Integrity & Approval

Live Demo

"Buy me wireless headphones under $350"

1 Agent calls shopOnlineTool

2 CIBA request → push notification to device

3 User approves on phone → agent resumes

4 Purchase completes — only after approval

Why this matters

Agent doesn't ask forgiveness — asks permission
Credentials never leave the secure vault
Agent knows when its authority ends

"By following these Three Laws, we move from 'Unconstrained AI' to
Verifiable Autonomy."

We aren't just building agents that work — we're building agents we can trust with our credentials.

1 Give your agent an identity, not a skeleton key — scoped, revocable tokens.
2 Enforce least privilege at the identity layer — not the model layer.
3 Make high-risk actions require explicit human approval.