Agent Permission Gateway: AI Agents on Least Privilege
A control layer between AI agents and their tools: narrow rights, short-lived tokens, approval gate, audit log. Demo architecture, not a product.
- Industry
- Cross-industry / mid-market / AI operations
- Build, estimated
- 4–6 weeks
At a glance
- It starts with
- Agent requests tool action
- The machine handles
- 9 of 10 steps
- A person keeps
- Human-in-the-loop approval
- Bottom line
- approval onlyIrreversible actions
The problem
Let's be honest: most AI agents today run on a shared admin API key and the hope that the instruction "be careful" is enough. It isn't.
The Replit incident — a deleted production database despite explicit instructions to the contrary — and EchoLeak (CVE-2025-32711, zero-click data exfiltration from M365 Copilot) show what happens when an agent is allowed to do more than it should.
This demo shows how a gateway in between makes the question "what rights does the AI have?" technically answerable — not via a prompt, but via permissions.
The moment an agent takes on real work, its permissions become the actual risk — not its hallucination. The OWASP Top 10 for Agentic Applications (December 2025) name it directly: ASI03 Identity & Privilege Abuse, ASI02 Tool Misuse, and ASI10 Rogue Agents.
In practice, most setups lack (a) a dedicated identity per agent, (b) tightly scoped rights per tool, (c) an approval before irreversible actions, and (d) a complete log of who triggered what. Instead: a shared master key and well-meant prompts.
The documented escalation patterns are concrete: delegation chains pass on the full privilege set instead of only what's needed; cached tokens get reused across users; authorization happens only at the start, not per step (TOCTOU). And almost every real incident is a confused deputy: nobody hacks the agent — they talk it into it via an instruction hidden in data.
The process, step by step
Scroll through. The diagram stays put and highlights the step you are on.
- 01
Agent requests tool action
e.g. change a record
An agent wants to use a tool — change a record, send an email, or trigger a payment. Instead of accessing the tool directly, the request runs through the gateway.
- 02
Check identity & scope
Who? Which rights?
The gateway first checks: which agent is asking, and what rights does this specific agent have? No shared admin keys — each agent has its own identity with a tightly scoped set of rights.
- 03
Issue JIT token
Vault · short-lived
For the specific task, a secrets manager (Vault) issues a short-lived just-in-time token. It is valid only for this one step and expires afterwards — a hijacked token is quickly worthless.
- 04
Authorize per step
Policy engine (OPA)
A policy engine (OPA) decides per step whether this specific action is allowed — not just once at the start. That closes the TOCTOU gap between check and use.
- 05Branch
Irreversible?
Now the key question: is the action irreversible or significant? Moving money, deleting data, communicating externally — or just something read-only and uncritical?
- 06Human decides
Human-in-the-loop approval
Slack / Teams
For irreversible actions, the request doesn't run through — it routes into an approval queue in Slack or Teams. A human decides, the workflow documents the decision.
- 07
In scope — no gate
allowed directly
Uncritical actions within the allowed scope proceed directly without a gate — least privilege only slows things down where it matters, not everywhere.
- 08
Execute tool action
only within scope
Only now is the tool action actually executed — strictly within the allowed scope and with the short-lived token. Even a talked-into agent can only do what it has rights for.
- 09
Write audit log
append-only
Every step — identity, token, authorization, approval, execution — is written append-only to the audit log: agent identity, tool, payload hash, override, timestamp.
- 10
Done & logged
auditable
The action is complete and fully logged. "Who approved this?" is now a database entry, not a crisis meeting.
What changes
Possible setup, not a packaged product
The figures are modelled target values for a possible setup, derived from industry benchmarks and our own tests. They do not come from a customer project; real values depend on your business. We do not sell this setup as a finished product: we measure where your bottleneck is, then build with your team. For systems that require certification (e.g. HIS, gematik, DATEV-certified) we work with specialised partners.
Before vs. After
| Aspect | Before | After |
|---|---|---|
| Access | Before: shared admin key for everything | After: dedicated, narrow credentials per agent |
| Irreversible action | Before: runs through unchecked | After: approval gate, human decides |
| Token | Before: valid forever | After: just-in-time, short-lived |
| Authorization | Before: checked only at start (TOCTOU) | After: checked per step |
| Traceability | Before: scattered logs | After: one immutable audit log |
| Prompt injection | Before: "be careful" in the prompt | After: external content = data, not commands |
Technology
Technology Stack
Integrations
Systems this setup can connect to
- n8n (self-hosted)Orchestration
- Central gateway engine: policy check, token issuance, approval gates, and audit log
- Make / ZapierAgent integration
- Existing AI workflows are routed through the gateway via webhook
- Vault / secrets managerJIT credentials
- Issues short-lived, task-bound tokens instead of hard-wired keys
- Policy engine (OPA)Authorization
- Decides per step whether a tool action is allowed — least privilege as code
- Slack / TeamsApproval gate
- Human approval for irreversible actions, right in the chat
- PostgreSQLAudit log
- Immutable record of all agent steps and approvals
Security & Compliance
What the setup takes care of
- Data sovereignty through self-hosting
- The entire gateway runs self-hosted (n8n) in your own data center or EU hosting. Agent credentials and audit data never leave the house.
- Least privilege enforced
- Rights are scoped finely per tool and issued short-lived. An agent can technically only do what it is authorized for right now — not whatever its shared key would happen to allow.
- External content treated as data
- Anything the agent reads from emails, documents, web pages, or tickets is treated as data, not a command — the basic defense against indirect prompt injection like EchoLeak.
- Immutable audit trail
- Every agent step and approval is logged append-only with timestamp, identity, and payload hash — traceable in incidents and disputes.
Frequently Asked Questions
What would this look like at your company?
This workflow is a demo. Whether it pays off for you depends on where things get stuck at your company. The method page shows how to find out. To place a workflow of your own, use the free assessment. No call needed.
Related Showcases
EU AI Act Cockpit: Prove Obligations Automatically
A central AI registry, an immutable audit trail, a human-in-the-loop gate and Article 50 transparency notices. Demo reference architecture.
Automate GDPR Access Requests (Art. 15)
A multi-agent system searches CRM, mailboxes, tickets and files in parallel, redacts third-party data, and the DPO signs off. Demo architecture.
Model Router Gateway: the smallest model that passes
A gateway that routes each task to the cheapest model passing your eval — frontier only for the hard step. Demo reference architecture.