ScopeGuard

Inspiration

The rise of agentic AI systems — where LLMs don't just answer questions but act in the world — introduced a security gap that existing OAuth frameworks weren't designed to handle. Traditional authorization assumes a human is making a decision at the moment of access. But AI agents operate autonomously, often with broad pre-granted permissions, and no mechanism to ask "does this specific action, right now, actually need this much access?"The breaking point was reading about real incidents where AI coding assistants exfiltrated data through prompt injection, and financial automation agents that executed irreversible transactions because nothing in the pipeline said stop and verify. ScopeGuard was born from one question: what if every agent action had to justify its own permissions, in real time, before execution?

What it does

ScopeGuard is a four-layer authorization gateway that sits between an AI agent and the tools it calls. Layer 1 verifies agent identity using Auth0 Machine-to-Machine tokens. Every agent has its own cryptographic ID no shared keys, no impersonation. Layer 2 enforces hard constraints in pure code — amount limits, domain whitelists, country sanctions lists (OFAC). This runs before any LLM is consulted, making it prompt-injection-proof by design. Layer 3 uses Google Gemini 2.5 Flash to decide the minimum permissions needed for this specific action — not the agent's full declared scope set. Least-privilege, decided dynamically per request. CIBA + Token Vault: if the action is high-stakes, the agent pauses. Auth0 CIBA sends a human-readable approval request to the user — in plain English, not OAuth scope strings. Once approved, a short-lived scoped token is issued, expiring in 300 seconds. Layer 4 verifies the output. Because authorization at input isn't enough — what comes back out needs to be checked too, for data leakage, PII exposure, and policy violations. The result: LLM-proof hard constraints, human-in-the-loop for high-stakes actions, and zero standing credentials.

How we built it

I designed ScopeGuard as a layered system combining identity, policy, and AI: Frontend & API: Next.js (App Router) Language: TypeScript Identity & Auth: Auth0 M2M applications for agent identity Token Vault for scoped token exchange CIBA for step-up user approval LLM Layer: Google Gemini (2.5 Flash) Determines minimal required scopes per action Generates human-readable consent explanations Validation: Zod for structured outputs Security Engine: Custom Layer 2 constraints (amount limits, domain whitelist, velocity caps, data classification) Centralized agent registry I also built four specialized agents (travel, fraud, AML, HR) to demonstrate different security profiles and real-world scenarios.

Challenges we ran into

At the beginning, even defining the problem clearly was difficult. I wasn’t just building an AI feature. I was trying to rethink how permissions should work when actions are driven by autonomous agents, not humans. I also struggled with finding the right balance between security and usability. If everything is locked down too strictly, the system becomes unusable. But if it’s too flexible, it defeats the purpose of security. Designing that middle ground took multiple iterations.

Accomplishments that we're proud of

Honestly, just being able to finish this project on time is something I’m really proud of. This was a completely new area for me, and building something this complex from scratch was a challenge in itself. Another accomplishment is bringing real-world security thinking into the project. I implemented constraints like transaction limits, domain restrictions, velocity controls, and data classification — making the system feel closer to something that could exist in production, not just a prototype.

What we learned

LLMs are powerful optimizers, not security enforcers Identity is necessary but not sufficient — control must happen at runtime Most AI security problems are actually authorization problems Users only trust systems they understand — clear explanations matter as much as enforcement Over-permissioning is the default — minimizing scope requires active design

What's next for ScopeGuard

PII detection in Layer 4 — scanning output for NIK numbers, credit card patterns, passport numbers before they reach the agent. Especially critical for the HR onboarding and AML compliance agents where sensitive documents are involved. Webhook support for CIBA — instead of polling, push approval status updates via webhooks so enterprise systems can integrate without maintaining open connections. Agent reputation scoring — track each agent's historical request patterns. An agent that repeatedly requests scopes it doesn't use gets a higher baseline risk score at L3. Scope vocabulary standardization — right now payment:write is a string convention. A proper implementation needs a registry — machine-readable scope definitions with risk metadata, mapped to actual API permissions. Multi-approver flows — high-value actions (e.g. transactions above $50,000) should require M-of-N approvals, not just one human confirmation.

Built With

• auth0
• gemini
• typescript