Agent Permission Gateway — securing AI agents with least privilege
A self-hosted control layer between AI agents and their tools: narrow per-tool rights, short-lived just-in-time tokens, per-step authorization, a human-in-the-loop gate before irreversible actions, and a tamper-evident audit log. Demo reference architecture, not a certified product.
- Irreversible actions
- approval only
- Industry
- Cross-industry / mid-market / AI operations
- Implementation
- 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.
How the process runs — 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.
Our Solution
A gateway that sits between agent and tools and enforces every tool use rather than requesting it — self-hosted for full data sovereignty. Four building blocks:
1. Identity & scope per agent. Each agent gets its own identity and a set of tightly scoped rights — read-only where reading is enough; a specific resource instead of a wildcard. No shared master key.
2. Just-in-time tokens. Rights are issued short-lived per task and expire — no permanent token that stays valid forever.
3. Human-in-the-loop gate. Irreversible actions (moving money, deleting data, communicating externally) don't run through — they route into a Slack/Teams approval. The human decides, the workflow documents.
4. Tamper-evident audit log. Every step is written immutably — agent identity, tool, input, output, timestamp, human override. "Who approved this?" becomes a database entry.
Honest framing: the gateway does not replace a full IAM/SIEM strategy and is not a certified security product. It makes least privilege for agents traceable, enforceable, and auditable — the framework is still set by a security owner.
- Per-tool scoping
- Read-only vs. write, a specific resource instead of a wildcard. An agent that reads invoices has no delete right — the OWASP recommendation to grant only the minimum tools, finely scoped, enforced technically.
- Just-in-time credentials
- Short-lived, task-bound tokens from a secrets manager instead of hard-wired keys. Once the task ends, the right expires — a hijacked token is quickly worthless.
- Human-in-the-loop gate
- Configurable thresholds (amount, action type, data class) trigger a human approval in Slack or Teams before an irreversible action runs. The Replit case would have been a non-event.
- Immutable log
- Append-only audit log with agent identity, tool, payload hash, override, and timestamp. The attribution gap — who actually acted, with whose rights — becomes a lookup-able entry.
What comes out of it
Possible setup, not a packaged product
The figures shown are target values and expected magnitudes for a possible setup – based on industry benchmarks, public studies of comparable setups, and our own tests on a real stack. They are not measured outcomes from a specific customer project; actual results depend on company size, process maturity, and integration depth. We do not offer this setup as a packaged product. We help teams design, automate, and run such processes themselves – through architecture consulting, workshops, and implementation support with n8n. For regulated third-party systems with certification or license requirements (e.g. HIS, gematik, DATEV-certified), we partner with specialized providers.
- only needed tools
- Rights per agent
- 100% approval
- Irreversible actions
- minutes
- Token lifetime
- every step
- Audit coverage
From "the agent has an admin key and we hope for the best" to "each agent has only the rights for its task, irreversible actions require approval, and everything is logged." Demo values, illustrative.
Before vs. After
| Aspekt | Before | After |
|---|---|---|
| Access | shared admin key for everything | dedicated, narrow credentials per agent |
| Irreversible action | runs through unchecked | approval gate, human decides |
| Token | valid forever | just-in-time, short-lived |
| Authorization | checked only at start (TOCTOU) | checked per step |
| Traceability | scattered logs | one immutable audit log |
| Prompt injection | "be careful" in the prompt | external content = data, not commands |
Technical facts
Technology Stack
Integrations
Seamless connection to your existing infrastructure
n8n (self-hosted)
OrchestrationCentral gateway engine: policy check, token issuance, approval gates, and audit log
Make / Zapier
Agent integrationExisting AI workflows are routed through the gateway via webhook
Vault / secrets manager
JIT credentialsIssues short-lived, task-bound tokens instead of hard-wired keys
Policy engine (OPA)
AuthorizationDecides per step whether a tool action is allowed — least privilege as code
Slack / Teams
Approval gateHuman approval for irreversible actions, right in the chat
PostgreSQL
Audit logImmutable record of all agent steps and approvals
Security & Compliance
Enterprise-ready with highest security standards
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
Does this look like your setup?
If this workflow resembles yours, we will look at it together — and tell you honestly whether automating it pays off.
Related Showcases
EU AI Act Compliance Cockpit – Prove Your Obligations, Automatically
Automate the EU AI Act and GDPR obligations themselves: a central AI registry, an immutable audit trail, a human-in-the-loop gate for automated decisions, and automatic Article 50 transparency notices. Deadline-safe instead of a spreadsheet.
Automate GDPR Access Requests: the Multi-Agent Crew (Art. 15)
Answer Art. 15 GDPR data subject access requests in days, not weeks: a multi-agent system searches CRM, mailboxes, tickets and files in parallel, auto-redacts third-party data, and the DPO signs off. Self-hosted, deadline-safe, auditable.