The thesis
Software is about to start acting on its own.
Companies are putting AI agents into production — writing code, moving tickets, messaging customers, touching records. Every one of those agents needs credentials. And there is currently no way to give an agent credentials of its own, so they are given a person's.
Before the argument
What Grenz actually is.
A firewall you run yourself, sitting between your AI agents and every service they call — GitHub, Linear, Slack, or any MCP server. It starts closed: every call an agent makes is refused unless your policy grants it. Your real credentials go in once and stay there — the agent only ever holds a token that works nowhere else — and the controls are built on the assumption that the agent can be tricked, not that it will behave.
And then the parts that make it usable in production
Budgets that cap how much an agent does per hour. Schedules that close the window entirely. Tokens that expire. Delegation, so a sub-agent inherits a subset of its parent's grants and dies with it. Content scanning on outbound bodies. Signed policy distribution to a fleet, and revocation that propagates and takes effect mid-task.
It is a single binary and a YAML file. It is open source, it runs on your infrastructure, and it decides locally — so it keeps working whether or not anything else is reachable.
Access control was built for humans who click things. Agents break every assumption in it.
The failing assumption
Identity systems encode a specific model of who is acting.
Not a person in the abstract — a person who logs in, holds a session, belongs to a directory, and can be asked what they were doing. That model is load-bearing, and every control built on top of it inherits the assumption. An agent satisfies none of it.
It cannot hold an identity
An agent has no account, no directory entry, and nothing to authenticate as. So it borrows a person's credential — which means from the first request, its actions and that person's are indistinguishable, in exactly the record you would consult to tell them apart.
It acts continuously, unattended
A person makes a handful of consequential decisions an hour and stops at night. An agent makes thousands, at machine speed, while nobody is watching. Controls calibrated to a human's pace — periodic review, someone noticing, rotation on a schedule — are tuned for a rate that no longer applies.
Its scope is knowable, and granted anyway
Permissions are coarse because a person's job is broad and changes. An agent's task is narrow and known in advance — it files pull requests, or it triages tickets. The gap between what it needs and what it holds is enormous, and unlike with people, it is entirely avoidable.
It can be persuaded by its own input
An agent that reads a support ticket, a web page, or a file cannot reliably separate content from instruction. This is not a bug awaiting a patch; it is a property of how these systems work. Which means the credential must be the constraint, because the agent's judgment cannot be.
Why the existing stack does not absorb this
The control point is architecturally different, in four ways that are hard to retrofit.
The reasonable objection is that identity providers already exist and will add agents as a feature. We think the shape of the problem resists that.
Identity systems answer who are you, once, at the start of a session. This problem needs an answer to may you do this specific thing, on every request, at the moment it happens. That is not a login — it is a decision in the request path.
It requires holding the real credential and swapping it in. The agent must never receive the thing it is using, or the entire control is advisory. That makes it a proxy, and proxies are a different product from directories.
Gateways and control planes are built to carry traffic, so their policy layers are additive on purpose: configure nothing and nothing changes. That is the right default for a component whose job is to keep requests flowing. It is the wrong one for a component whose job is to stop them. A permission layer has to start closed — anything not granted is refused — which is a different default, and defaults are not something you retrofit.
If permission requires a network round-trip, every agent action inherits that latency and that availability — and the first outage forces a choice between blocking all work and failing open. Neither is acceptable, so the decision must happen next to the agent, which rules out the shape most SaaS control planes take.
Prevention has to sit in the request path. Everything else is telling you afterwards.
Product as proof
The argument is only worth as much as the thing built on it.
Grenz exists, runs today, and is open source. Each claim below is a shipped mechanism, not a roadmap item.
An agent holds a token that works only through the proxy, and can be given an expiry. Real credentials never leave it — not into a log, an error, an approval prompt, or the cloud plane.
A pure, synchronous policy engine decides each request before anything is forwarded. Anything not granted is refused, including on a malformed policy or a vault failure — there is no path where confusion means allow.
Actions you mark risky block in-flight until someone approves them, from Slack or a terminal, with a quorum if you require one. An approval nobody answers expires into a denial.
The engine is embedded in the proxy — no network call on the decision path. Losing the control plane means proxies keep enforcing the last policy they verified, not that they stop.
Budgets cap actions per hour; schedules close the window; responses are capped so a read does not become a bulk export; outbound bodies are scanned for credential shapes; and agent traffic can move onto a socket reachable only by your own OS user.
Lint a policy, simulate it against recorded traffic, run it in shadow mode or on a canary slice, then enforce — and roll back to any previous version if you were wrong.
Revocation takes effect mid-task, with no restart — before the next upstream call, policy check, or credential fetch. Revoking a parent cuts off every sub-agent it spawned, and across a fleet it propagates.
Read the security model for where the boundary actually falls — it is written to claim less than a reader might assume, not more.
Where this goes
Individual, then team, then shared.
The wedge is a developer installing a single binary in front of one agent, because that is a decision one person can make on a Tuesday. The shape after that follows the pattern access control has always taken.
Shipped
The local proxy
Open source, runs on your machine, one policy file. Solves the problem for the person who felt it first, without asking anyone's permission.
Shipped
The team plane
One policy distributed to every proxy in a fleet, signed and verified, with revocation that propagates. The proxy still decides locally; the plane only tells it what the rules are.
Next
Shared policy
Most teams are wrapping the same handful of tools. A registry of reviewed starting policies makes the safe configuration the default one, and gets better the more it is used.
Limits
What we are not claiming.
A security product that overstates its boundary is worth less than one that draws a smaller boundary honestly.
Grenz controls what an agent can reach through it. Software already running on your machine as you is inside that boundary. It does not inspect a model's reasoning — it sees actions, not intentions. It is not an evidence or compliance product; the activity log is there so you can see what happened operationally, and it makes no guarantees beyond that. And it does not remove the need to scope credentials at the source. It narrows what an agent may do with access it has been given; it cannot narrow what that access is capable of if it escapes.
We would rather be right about a smaller claim. The bet is not that this is the whole answer — it is that the decision about what an agent may do has to happen before the action, next to the agent, and that nothing occupying that position exists yet.