Let AI agents act inside your organization, without giving them the keys.
Short answerTunnel Zero-Trust is infrastructure for AI agents that work with an organization’s own systems. Each agent gets its own identity and a set of explicit capabilities. Its requests go through a Tunnel connector, which refuses anything not granted, sends consequential actions to a named person through Flamecloak, adds the real credential only after a call is allowed, and records every call. The agent never holds the credential. It is in development and not available yet.
In development. There is no date we could honestly give you, so there is none: leave your address and we will write when there is something real to try.
The agent does not own access. Tunnel grants capabilities.
An agent can have legitimate credentials and still make an illegitimate decision: a prompt injection, a misread instruction or a plain reasoning error turns authorized access into an outcome nobody authorized. So the agent is given no standing access at all.
Its own identity
Every agent is registered on its own, with its own key and the person or team it acts for. A key can be revoked at any moment, and the record always says which agent acted.
Explicit capabilities
A capability is one HTTP route or one MCP tool, and it is allowed, sent to a person, or refused, under conditions you write, such as refunds below a set amount. Anything not granted is refused: the default is no.
The credentials stay with Tunnel
The connector holds the API keys and tokens. The agent sends its request without them, and Tunnel adds the credential after the call is allowed. A credential the agent tries to send itself is removed.
A person for the consequential ones
Some actions must not happen until someone says yes. Flamecloak’s approvals are part of the product: the call waits, a named person decides, and only then is it made, once.
Only the data the task needs
A capability can pass on only some fields of a response, such as a customer’s status and order history without their payment details. A response that cannot be trimmed safely is refused rather than passed on whole.
Limits over many calls
A rule for one call can be split into many small ones. A capability can also carry a running total per agent, a number of calls or a sum per day, and what goes over it is refused or sent to a person.
A record of every call
Allowed, refused or decided by a person, every call is recorded with the agent, the capability and the outcome, in a hash-chained log you can check. Request bodies and credentials are never in it.
What happens to one request
In this order, every time.
The agent is identified
Its key says which agent this is. An unknown or revoked key is turned away before anything else happens.
Its own credentials are removed
Anything that looks like a credential in the agent’s request is stripped. The only credentials that reach your systems are the ones Tunnel holds.
A capability is found, or the call is refused
The request is matched against what this agent was granted. Nothing matches: refused, and the reason recorded.
The conditions are read from the request itself
Amounts and identifiers are taken from the request Tunnel is about to send, never from what the agent says about it.
A person decides, when the capability says so
The call waits while a named person approves or refuses it. What they approve is exactly what is sent.
The credential is added, and the call is made once
Tunnel adds the credential and makes the call itself, exactly once.
The response is trimmed, and the call recorded
Fields the capability does not pass on are withheld, and the call goes into the record.
Where it runs
The part that holds your credentials sits where they already are. Everything a person does is in your Tunnel dashboard.
In your network
The connector runs inside your network, next to the systems it protects, as a container or a service. It only connects outwards, so it needs no inbound port.
Or on Tunnel’s side, for public services
For public APIs such as a payment provider, the connector can run on our side instead, one per organization. It reaches only the services you named, over HTTPS, and never an internal address.
Everything a person does, in the dashboard
Registering agents, granting capabilities, approving actions and reading the record all happen in your Tunnel account.
What Tunnel Zero-Trust does not claim
The boundary holds only if the agent cannot go around it. The machine the agent runs on must hold no credentials and reach nothing but the connector, which is a network rule on your side. We will ship reference configurations and a check that proves it from the agent’s side; until that rule is in place, not every interaction crosses the boundary.
The connector sees every request and response that passes through it. In your network it runs on your hardware, under your control, and its record never holds bodies.
A capability with no response rule passes on the whole response. Trimming is chosen capability by capability, and the dashboard shows which have none.
It does not filter records by subject, such as leaving unrelated customers out of one response. That is separate work, built when somebody asks for it.
It does not judge whether an agent is right. It decides what the agent may reach by rules you write; no model and no score takes part in that decision.
There is nothing to buy or try yet, and no date.
Questions people ask about this
Do our agents have to be rewritten?
No. An agent sends its HTTP requests and MCP tool calls to the connector instead of straight to the service, with its own Tunnel key. Nothing else in it changes, and it does not need to know Tunnel exists.
How does it relate to Flamecloak?
Flamecloak is Tunnel’s action-authorization layer, and its approvals are included: a capability that needs a person uses the same approvers, the same approvals on a phone and the same record. You do not need a second product.
Where do the credentials live?
In the connector, sealed at rest, and nowhere else. They are never sent to us, never written to a log, and never shown again once entered. When the connector runs on our side for a public service, the value you type is encrypted in your browser for that connector alone, and our servers pass on only what they cannot read.
What happens when an approval takes a while?
The connector holds the call for a short time, so a quick approval answers on the same request. After that it tells the agent to try again, and the same request sent again finds the same decision instead of opening a new one. Once approved, it runs once.
Is the decision a risk score?
No. Whether a call is allowed, refused or sent to a person comes from conditions you write over the request itself: an amount, an account, a field. No model scores it, and the record says which rule decided.
When can I use Tunnel Zero-Trust?
There is no date, and an invented one would be worth nothing to you. It is in development, has no price and nothing to sign up for. Leave your address on this page and we will write when there is something real to try.