Why I built Agentgate: a stolen agent session is worse than a stolen account

Artificialxtrax — Tue, 20 Oct 2026 15:53:29 +0000

A stolen session cookie used to mean someone could read your email or change your password. On a platform that runs AI agents, it means something worse: the thief gets a tireless assistant that already has your tools, data connections and webhooks. It will export your records to a new endpoint, call APIs on your behalf and do it quickly, all while looking like you. Most of the defensive tooling I found for agents worked on a different problem, filtering harmful prompts. Very little asked the earlier question: is this request actually from the owner?

agentgate is my attempt at that question. It's a small Python library, one dependency (cryptography), that sits in front of an agent and screens each request before it runs.

No single check works, so stack cheap ones
Every signal I looked at had an easy bypass on its own. Device IDs can be copied. TLS fingerprints can be impersonated. IP reputation fails against residential proxies. Behaviour baselines miss a patient attacker who acts like the owner. So agentgate layers them. Each layer catches a different kind of attacker, and the README has a table listing what each one does not catch.

The second design rule matters as much: behavioural signals never block. New phones, VPNs and travel are common and innocent. A suspicious signal triggers a step-up, meaning re-verify. It never triggers a ban. On synthetic data, owners on a normal day see no added friction, while a token thief running a script from a datacenter is stepped up every time.

The layer that actually holds: a key tap bound to the action
The hardest case is malware inside the owner's own browser. It has the right cookies, device, network and typing. Nothing behavioural catches it. What it can't do is produce a WebAuthn signature from the owner's physical key or passkey for a challenge it didn't get the user to approve.

So sensitive actions ("export to hooks.acme.com", "change destination", "run privileged tool") require a one-time challenge bound to that exact action string. A signature for one action can't be replayed or reused for another. That's a property of the protocol, not a detection rate, and it's the part I'm most confident in. It's also the part I most want someone else to check: the verifier is hand-written, it has been tested against a spec-following software authenticator and one real Apple passkey, and it hasn't been through the FIDO conformance suite.

Keep a record nobody can quietly rewrite
Every decision, and every event that extends trust (enrolment, key revocation, reinstatement), goes into a hash-chained audit log. The log stores keyed hashes, not raw text or IPs. The chain's Merkle root can be anchored externally, for example via OpenTimestamps, so even whoever runs the server can't silently rewrite history.

Being honest about where it stands
agentgate is alpha. It has 145 tests, a red-team harness with simulated owners and attackers, and a self-audit that found and fixed 24 defects. It has not run against real traffic, a live model or standalone hardware keys, and it hasn't had an independent review. The thresholds are guesses you should calibrate in shadow mode on your own traffic. I also mapped it against the OWASP Top 10 for LLM Applications (2025). Most entries are Partial or Out of scope, because agentgate guards the door, not the model.

What I'm asking for
If you know WebAuthn, please try to break webauthn.py and approval.py. If you run an agent platform, tell me which signals would be noise for your users. REVIEW.md lists where to start, and security reports go through SECURITY.md or Artificialxtrax@outlook.com.

Install: pip install agentgate-security

Repo: https://github.com/Artificialxtrax/agentgate (MIT).

DEV Community: Artificialxtrax

Why I built Agentgate: a stolen agent session is worse than a stolen account