Permission isn’t approval.
Flamecloak catches your riskiest API calls before they run and asks a real person to approve them
No newsletter, no sales call. One message when there is something you can try.
Your systems already know who may connect. Nothing asks whether this export, this payment, this deletion should happen at all. Flamecloak is being built to ask.
Every organisation has APIs that return things nobody should touch casually — bulk exports of customer data, document downloads, credit decisions, irreversible writes. Access control says who can reach the system. Nothing says this specific action, right now, needs a person to say yes.
That gap is the canonical insider-risk vector, and it is getting worse, because AI agents now call those same APIs.
Flamecloak plugs into the proxy you already run — Envoy, NGINX, Traefik, your API gateway. It starts in observe mode, blocking nothing, and within thirty minutes tells you which endpoints returned personal data, to whom, and how much. Then you turn on gating for the handful that matter. A request arrives, we resolve who is actually permitted to approve it, that person signs the specific action with a passkey, and the executing system won’t proceed without that signature.
None of this needed anybody to break in.
Four shapes of loss, every one of them carried out by an account that was allowed to do it.
- Bulk export, valid credentials
- Documents pulled one by one
- Payments released unattended
- Agents acting with your keys
All four are permitted. That is the problem.
Three numbers, one report, and the page for each.
- 48%
of breaches involved a third party, up from 30% the year before.
- 36%
of breaches involved the use of stolen credentials, which is where that figure has sat for years.
- 45%
of employees are now regular users of AI on their work devices, up from 15% a year earlier.
The account that does the damage is usually allowed to.
Most serious data loss involves credentials that were real, a permission that was current, and a request that looked like every other request that day. Nothing was broken into. Somebody who was supposed to be able to do it did it, at a scale nobody had thought about, and the system did exactly what it was configured to do.
That is not a configuration mistake. Permissions are granted to people and to systems, never to individual actions. Somebody who needs to read customer records to do their job can, by the same grant, read all of them at once. A script with a valid key does not get more suspicious the ten-thousandth time it runs. The question was asked once, at the door, and never again afterwards.
So the useful question goes unasked, because there is nowhere to ask it. Not "may this account do this" — every system answers that already, instantly, correctly, and it is not the question. The one that matters is whether this particular thing, at this size, right now, should be done at all.
Organisations where some actions must not happen until a named person says yes.
The export nobody looks at
An analyst pulls customer records to answer a question. The same permission that returns one row returns four hundred thousand, with dates of birth and national identifiers among them. Nothing was broken into and no rule was bent.
Held until somebody accountable has seen the size of it.
GDPR Art. 5(1)(f) · Art. 32
The payment that cannot be recalled
A scheduled job releases a payment run at four in the morning. The person answerable for it has never watched one go out.
Held until the person answerable for it has watched one go out.
financial controls: segregation of duties
The deletion that was meant to be one row
A maintenance script, a missing clause, and a table instead of a record. The difference between an inconvenience and an incident is whether anything stood between the intent and the effect.
Held until the shape of what is about to go is on somebody's screen.
GDPR Art. 5(1)(f) · retention and integrity
An agent acting on your behalf
Software that decides its own next step now holds your credentials, and it does not get more cautious the ten-thousandth time it runs. It is asked the same question everybody is asked. The difference is that nobody is watching the session it is inside, because there is no session and no person in it.
Held until a person has seen which agent is asking, and for what.
no obligation names this yet
The document that walked out
A support tool lets one contract be opened by its id. Nothing stops the ids being asked for in order. Over a weekend the whole folder leaves: signed agreements, identity packets, the scans somebody sent once and forgot about. Every request was permitted and every one was answered correctly.
Held the first time it is asked. There is no tenth to wait for, and so no threshold to stay under.
GDPR Art. 32
The decision that changed someone's life
An eligibility decision is released without a person on it. A credit line, a claim, a place on a list. It is correct as often as the model is correct, and the person it happened to has nobody to ask, because nobody decided. What is held here is the release, not the judgement: the record says a named person answered, never that the answer was right.
Held until a named person has answered, and the record says who.
GDPR Art. 22
Where it sits, and what it signs.
It runs in the path the request takes, in front of the systems it protects and inside your own network. It starts in observe mode, holding nothing, and reports what is actually being asked for.
It watches before it holds anything.
The first thing you get is a description of your own traffic: which endpoints return the most, which return personal data, and who is calling them. You decide what deserves a hold from that, rather than from a list we wrote.
Then a person decides, and the record says who.
A held action stops at the gateway and never reaches your systems until somebody entitled to authorise it has signed. If nobody is entitled, nothing is held — the gateway will not invent an approver.
| endpoint | calls | rows returned | PII classes | callers |
|---|---|---|---|---|
| GET /v1/invoices | 8,417 | 412,006 | 1 | 22 |
| GET /documents/{id} | 22,940 | 22,940 | 3 | 4 |
| DELETE /records | 94 | 1,890 | 2 | 5 |
| GET /v1/customers?limit= | 6 | 2,400,000 | 4 | 1 |
| POST /payments/runs/{id}/release | 31 | 31 | 0 | 3 |
| GET /v1/customers/{id} | 1,204 | 1,204 | 4 | 9 |
Four things we will be held to.
None of it is checkable yet, because there is nothing to run it against. When there is, this page will say so and change.
It runs inside your own network.
The gateway sits in your infrastructure, in front of the systems it protects. Your traffic does not pass through us, we keep no copy of it, and there is no account with us whose outage can stop your business. What you deploy is yours to run.
Every decision leaves a record you can check without us.
Who asked, what exactly was about to happen, who was entitled to answer, who did, and when. The record is tamper-evident, and an auditor can verify the whole sequence independently — with a tool that never contacts us and does not need our permission.
- who asked
- svc-reporting (script), holding a.dumitru credentials
- what was about to happen
- GET /v1/customers?limit=400000 · 4 PII classes
- who was entitled
- data protection officer, head of support, CTO
- who answered
- M. Ceban · passkey · device bound
- when
- 2026-03-11 09:41:57 UTC
- previous entry
- sha256:9f4c8e21…a71e
It never decides. A named person does.
There is no model here and no scoring. The gateway works out which humans are actually entitled to authorise this particular action, and puts the question to one of them. The judgment is theirs, the responsibility is theirs, and the record says which of them it was.
The unit is the action, not the session.
Access control decides who may be in the room. This decides what may happen while they are — this export, at this size, right now. It asks the question your existing controls ask once, at the door, and never again afterwards.
What it will not do.
It does not decide anything. It puts the question in front of a person; the judgment is theirs and so is the responsibility for it. Anyone selling you automated judgment about identified people is selling you a different and much larger problem.
It does not know whether the person was right. It can record that they were asked, what they were shown, and what they answered. Whether that was the correct answer is not a thing software knows.
It cannot see what does not pass through it. Data pulled straight out of a database by somebody with direct access leaves nothing for this to hold, and no amount of configuration changes that. A deployment that gives false assurance is worse than no deployment.
You cannot buy it. It is in active development, there is no date, and we will not invent one. You can ask for it and a person will answer you, but everything above describes what is being built, not what is on offer.
Leave an address and we will tell you.
No newsletter, no drip sequence and no sales call. One message when there is something you can actually try, and you can leave the list from any email we send.
Or ask for it.
Create a Tunnel account and ask for Flamecloak from your dashboard. Somebody will get in touch. It commits you to nothing, and there is still nothing to download.
Create an accountQuestions people ask about this
Can I use this today?
No. It is in active development, and there is no download and no trial. There are two things you can do: leave an address and we will write when there is something to try, or create an account and ask for it, and somebody will get in touch. Neither one holds you a place in a queue, because there is no queue. We have not set a date and we are not going to guess at one publicly.
How will it deploy?
Inside your own network, alongside the proxy or gateway already in front of your systems. The actions you choose to hold are routed through it and nothing else is. There is no appliance to buy, nothing of ours in your traffic path, and no data leaving your infrastructure for us to see. What it costs you is a route and a decision about which actions are worth holding.
What will it show me before I hold anything?
It watches first and holds nothing. In observe mode it reports which of your endpoints returned personal data, to whom, how much and how often, and no request behaves any differently while it does. The first useful output is a list of the endpoints you did not know were returning what they return. Nothing is held until you name something to hold.
Does everything have to go through it?
No, and it is being built on the assumption that it must not. Only the actions somebody has deliberately chosen to hold are affected; everything else is untouched. A control that has to sit in front of everything is a control nobody deploys.
What happens when the person who should approve is unavailable?
Entitlement resolves to a set of people rather than to one individual, so unavailable has to be true of all of them before it is true at all. If it is, the held action does not proceed. That is the honest failure mode and it is a delay rather than a loss, because the request can be made again. It is also why the choice of what to hold is yours, action by action. We are not going to promise you an escalation feature that is not designed.
Will it slow things down?
For the actions nobody chose to hold, nothing changes. For a held action the latency is however long the person takes to answer, and that is the product rather than a cost of it. There is an overhead budget for the unheld path in the build brief. We will publish the number when there is something to measure it against, and not before.
Is this the same as privileged access management?
No, and it does not replace one. Access management decides who may be inside a system and for how long. This is about the individual actions taken while they are — a different unit of authorization. If you do not have access management yet, that is the more urgent thing.
What happens if your service is down?
Nobody should accept a company of our size as a single point of failure in their production path, and we do not expect anyone to. The concrete part of the answer already holds: nothing of ours runs in your traffic path. What decides your requests runs inside your own network, so there is no service of ours for it to depend on. Being removable is a requirement in the build brief rather than a reassurance in a sales conversation.
How does an AI agent get approved?
A person is asked, the same as for any other caller. What that person sees is which agent is asking, the exact action, and the scope it wants. What they do not get is a score. The product will not tell you whether the agent’s intent looks benign, because that is a judgment about something nobody can inspect, and selling it would be selling the automated judgment this page argues against.
Why will you not say how it works?
Because what is withheld is the internal design rather than the deployment shape. Where it runs, what it shows you before it holds anything, what happens when nobody answers, and what it costs the requests you did not hold are all on this page, because those are the things you would hold us to and they stay true whichever way the implementation goes. How the holding is built is a different question, and answering it hands a competitor the design in exchange for nothing you need before there is something to try.
Where is the company?
"STILL BETA TECH" SRL, registered in Chișinău, Republic of Moldova. Moldova is not an EU member state; we process personal data under the GDPR and under Moldovan Law 133/2011, and we say so rather than implying an establishment we do not have.