Guardian Agent

AI security copilot — read-only by default, write-only with your permission

Comment

## Inspiration

Most AI agents today get broad, permanent access to user accounts. Once you grant a GitHub or Google OAuth token, the agent can read, write, and delete — indefinitely. We asked: what if agents defaulted to read-only and could only escalate with explicit, time-bounded human approval?

## What it does

Guardian Agent is an AI security copilot that monitors your connected accounts for threats using Auth0 Token Vault's progressive authorization model.

  1. Read-Only Baseline — Connect your GitHub and Google accounts through Auth0. Guardian exchanges for read-only scoped tokens via Token Vault to scan repositories for exposed secrets and check account settings for suspicious configurations.

  2. Threat Detection — The agent identifies critical security issues — hardcoded AWS keys, suspicious email forwarding rules, unauthorized app installations — and presents them as actionable threat cards with severity ratings and evidence.

  3. Step-Up Remediation — When a threat requires action, Guardian doesn't just act — it asks permission. A step-up approval shows exactly what new scopes are needed and why. On approval, Token Vault mints a 60-second write token.

  4. Auto-Revert — After remediation (e.g., creating a GitHub issue to report the exposed secret), the write token expires. Access automatically reverts to read-only. Every step is logged in an immutable audit trail.

## How we built it

  • Next.js 14 with TypeScript for the full-stack application
  • Auth0 Token Vault for all OAuth token management — zero provider refresh tokens stored in our database
  • Token exchange via urn:auth0:params:oauth:grant-type:token-exchange:federated-connection-access-token
  • Vercel AI SDK for the agent intelligence layer
  • SQLite for local audit trail and threat persistence
  • shadcn/ui for the dashboard interface

## Challenges we ran into

  • Designing the progressive authorization flow so the UX felt natural, not disruptive — users need to understand why the agent is asking for more access without feeling nagged
  • Managing token TTLs correctly so write access genuinely expires and doesn't silently persist
  • Building a convincing threat detection pipeline that works with read-only GitHub API scopes

## What we learned

Progressive authorization with time-bounded escalation should be the default pattern for agentic AI. Most agents don't need write access most of the time. By defaulting to read-only and requiring explicit step-up for writes, you dramatically reduce the blast radius of any agent compromise.

The audit trail tells the story: "Agent detected threat at 14:23. User approved write access at 14:23:52. Agent created issue at 14:23:55. Token expired at 14:24:53."

## What's next for Guardian Agent

  • Support for more identity providers (Slack, Jira, AWS IAM)
  • Configurable policy engine for custom escalation rules
  • Team-level dashboard with role-based approval chains

## Bonus Blog Post

### Progressive Authorization: From Read-Only Monitoring to Step-Up Remediation with Token Vault

When you give an AI agent access to your GitHub account, what scopes does it get? Typically: everything. Full read and write access to all repositories, the ability to delete code, create issues, modify settings. And once granted, that access persists indefinitely.

But here's the question security teams are asking: does a monitoring agent really need write access? If its job is to scan repositories for exposed secrets, why can it also delete repos?

The answer is obvious — it shouldn't. But traditional OAuth flows make it all-or-nothing.

Guardian Agent takes a different approach: read-only by default, write-only with step-up approval.

Using Auth0 Token Vault, Guardian connects to your GitHub and Google accounts with strictly read-only scopes. It scans repositories for exposed secrets, checks Gmail for suspicious forwarding rules, and reviews installed GitHub apps. All with read-only tokens that cannot modify anything.

When Guardian finds a threat — say, an exposed AWS access key — it can't just fix it. Instead, it requests step-up authentication through Auth0's Token Vault exchange. The user sees exactly what additional access is needed (repo:write), why it's needed ("Create issue to report exposed key in config.js"), and for how long (60 seconds).

The 60-Second Write Token

On approval, Token Vault mints a write token with a 60-second TTL. Guardian creates a GitHub issue documenting the exposed secret — file path, line number, remediation steps. Then the token expires. Access reverts to read-only automatically.

If Guardian were compromised during those 60 seconds, the attacker could create issues on one repository. Compare this to traditional approaches where a compromised agent with permanent write access could delete repositories, push malicious code, or exfiltrate data — indefinitely.

What We Learned

Building Guardian surfaced a pattern we think should be standard: progressive authorization with time-bounded escalation. Most agents don't need write access most of the time. By defaulting to read-only and requiring explicit step-up for writes, we dramatically reduce the blast radius of any agent compromise.

Token Vault made this possible by handling the complexity of multi-scope OAuth management and ephemeral token minting behind a single exchange API.

Bonus Blog Post

### Progressive Authorization: From Read-Only Monitoring to Step-Up Remediation with Token Vault

When you give an AI agent access to your GitHub account, what scopes does it get? Typically: everything. Full read and write access to all repositories, the ability to delete code, create issues, modify settings. And once granted, that access persists indefinitely.

But here's the question security teams are asking: does a monitoring agent really need write access? If its job is to scan repositories for exposed secrets, why can it also delete repos?

The answer is obvious — it shouldn't. But traditional OAuth flows make it all-or-nothing.

Guardian Agent takes a different approach: read-only by default, write-only with step-up approval.

Using Auth0 Token Vault, Guardian connects to your GitHub and Google accounts with strictly read-only scopes. It scans repositories for exposed secrets, checks Gmail for suspicious forwarding rules, and reviews installed GitHub apps. All with read-only tokens that cannot modify anything.

When Guardian finds a threat — say, an exposed AWS access key — it can't just fix it. Instead, it requests step-up authentication through Auth0's Token Vault exchange. The user sees exactly what additional access is needed (repo:write), why it's needed ("Create issue to report exposed key in config.js"), and for how long (60 seconds).

Built With

Share this project:

Updates