• Paths nobody named
  • Usual hours
  • Sudden floods
  • Another person’s yes

An independent line of defense in addition to your existing ones.

Stolen passwords are no longer enough to compromise your service.

Short answer

Flamecloak and Tunnel t0 (Zero-Trust) add a layer most organizations do not have: a check at the moment of the action, not only at sign-in. An action that matters can wait for one or several named people; a call outside its usual hours or in a sudden flood can wait or be refused; paths nobody named can be closed; and every decision lands in a tamper-evident record. They do not replace your firewall, your sign-in or your patching, and they protect what passes through them.

the gap attackers use

Most defences ask one question, once, at the door: is this the right password? After that, whoever holds it is trusted with everything the account can do, at any hour and at any pace.

Tunnel asks again at the action: should this happen, now, at this size, and who says yes?

Flamecloak

Start with the door everyone tries: your admin panel.

Put the sign-in to your admin panel behind Flamecloak, and every sign-in waits until a second person approves it on their own phone.

  • A leaked password opens nothing.

    Whoever bought it, guessed it or read it off a note still needs somebody else to say yes. A correct guess is worth no more than a wrong one.

  • The person approving sees where it comes from.

    Roughly where the sign-in comes from and on what device, if you choose to show it. A sign-in from a country nobody works in is an easy no.

  • Not at three in the morning.

    Give the panel its usual hours, and a sign-in at night is refused outright or waits for a person, as you choose.

  • Every attempt is on the record.

    Approved or refused, each sign-in is recorded with who answered, in a record nobody can quietly change.

TunnelWaiting for your approval

Sign-in to the admin panel

Account
admin, as the request stated it
Where
Lisbon, Portugal (approximate)
Device
Windows · Chrome
When
03:12, outside usual hours
An illustration of what the person approving can be shown, not a screenshot.

Rules you already understand, used as defences.

Each one is optional, is set action by action, and says what it stops in plain words.

  • Night-time calls wait.

    Say when an action is normally used. A call outside those hours, the time attackers prefer because nobody is watching, goes to a person or is refused.

    Stopsthe overnight export, the weekend sign-in

  • A flood stops at the limit.

    Say how many calls an action usually sees, in total and for each caller. When a stolen account starts reading at a hundred times its usual pace, the excess waits or is refused, and the people responsible are told once, not ten thousand times.

    Stopsbulk data theft, scraping, a script or an agent stuck in a loop

  • One yes is not enough.

    Ask for several people’s approval on the actions that matter most. One stolen phone, one tricked colleague or one bribed insider cannot approve it alone, and nobody approves their own request.

    Stopsa single compromised approver, fraud by one insider

  • Some things nobody may do.

    Mark an action as forbidden and it is refused for everyone, with no button anywhere that releases it. Nobody can be talked into it at four in the morning.

    Stopsdeleting the logs, switching off backups, the export that should never exist

  • Paths nobody named stay closed.

    Attackers look for the endpoint you forgot: an old admin page, a debug route, an export nobody uses. Turn this on and any path your rules do not name is refused instead of passed through.

    Stopsprobing for forgotten back doors

  • Refusals do not go unnoticed.

    When calls are refused for arriving at the wrong hour or too fast, the people responsible hear about it within the hour, with how many. An attempt is noticed while it is happening, not in next quarter’s audit.

    Stopsan attack that runs for days because nobody looked

What an attacker meets.

The attacks organizations actually face, and what changes once the actions that matter go through Tunnel.

  • A stolen or phished password

    Without it: It opens everything the account can do.

    With Tunnel: The actions that matter still wait for another person, on their own device.

    Flamecloak
  • A hijacked session or laptop

    Without it: The attacker is already signed in.

    With Tunnel: A session cannot approve anything. A yes comes only from the approver’s own phone.

    Flamecloak
  • Bulk data theft

    Without it: Every record, one request at a time, all night.

    With Tunnel: Held or refused outside the usual hours and past the usual pace, and somebody is told within the hour.

    FlamecloakTunnel t0
  • A compromised server

    Without it: Its keys reach every system it talks to.

    With Tunnel: The gate is not on that server, so it cannot be switched off, loosened or made to approve its own calls.

    Flamecloak
  • An insider acting alone

    Without it: One person with access needs nobody else.

    With Tunnel: Several people must agree, nobody approves their own request, and the record says who did what.

    FlamecloakTunnel t0
  • A tricked AI agent

    Without it: It holds your keys and follows a planted instruction.

    With Tunnel: It holds no keys, may do only what it was granted, and the consequential steps wait for a person.

    Tunnel t0
  • Probing for forgotten endpoints

    Without it: An old route answers like any other.

    With Tunnel: Paths your rules do not name are refused.

    Flamecloak
  • Covering the tracks

    Without it: Logs on a breached server can be edited.

    With Tunnel: Every decision is kept in a tamper-evident record that an auditor can check without us.

    FlamecloakTunnel t0
Tunnel t0

When the attacker is in the prompt.

An AI agent reads email, web pages and documents, and any of them can carry instructions meant to turn it. Tunnel t0 (Zero-Trust) assumes that one day one will, and limits what a turned agent can do.

Explore Tunnel t0
  • Nothing to steal.

    The agent never holds your credentials, so a tricked or compromised agent cannot leak them or reuse them elsewhere.

  • Only what it was granted.

    Every capability is granted on its own and anything else is refused. A planted instruction cannot add to the list.

  • Only the data the task needs.

    A capability can pass on only some fields of a response, so a turned agent reads less than it asks for.

  • No splitting under the limit.

    Limits hold across many calls, so one large payment cannot be broken into many small ones.

  • A person for the consequential steps.

    The action waits for a named person, who approves exactly what will happen, and it happens once.

Why the safest place for the guard is not your server.

Most teams let us run Flamecloak for them, and for security the reason is distance. A guard is only as strong as the place it stands.

  • Out of reach of a breach.

    If an attacker takes one of your servers, the gate in front of your systems is not on it. They cannot switch it off, change its rules or approve their own calls.

  • Approvals from people, not machines.

    A yes comes from the approver’s own device. A compromised server can ask as often as it likes; it cannot answer.

  • A record they cannot rewrite.

    Every decision is written on our side, where nothing can change it afterwards, so an intruder cannot erase what they tried.

  • Shut, not open, when we are unreachable.

    If our service cannot be reached, actions that need a person, or are forbidden, are refused rather than let through.

  • Improved without a project on your side.

    We run it and update it, so a new safeguard reaches you without anyone on your team planning an upgrade.

Inside your own network, when it must be.

Teams that cannot send traffic through anyone else run Flamecloak in their own infrastructure, on machines kept apart from the servers it guards, with no live connection to us.

What each part of the organization gets.

  • Security

    Fewer incidents become breaches.

    A stolen credential stops at the action, and you hear about refusals within the hour instead of finding them in a report.

  • Finance

    Money does not move on one person’s say-so.

    A payment, or a change to where money goes, can need two people, who can see what is being changed before they agree.

  • Compliance and data protection

    Evidence, not assurances.

    A tamper-evident record of who asked, who approved and what was refused, which an auditor can check without us when somebody asks what happened.

  • Engineering

    No rewrite.

    A route in front of your API or one call in your code. It watches before it holds anything, and holds only what you choose.

  • Leadership

    A smaller worst day.

    The damage a stolen account can do is capped by the rules you set, not by everything that account could reach.

stated limits

What it will not do.

  • It does not stop phishing, and it does not find the hole an attacker came in through. It limits what they can do afterwards, in the systems you put behind it.

  • It protects only what passes through it. A vendor’s own website, such as your bank’s portal, or a database somebody reaches directly, is out of its reach.

  • Somebody patient enough to keep to normal hours and a normal pace is slowed, not stopped. That is why the actions that matter most should also wait for a person.

  • An approval is only as good as the person giving it. Several approvers make one fooled person harmless; they do not make everyone careful.

  • A sign-in page can wait for an approval only when the sign-in passes through Flamecloak, and some older panels need a small change first. We look at yours with you before promising it.

  • It is not a firewall, an antivirus or a sign-in system, and it replaces none of them. It is the layer after them.

  • Neither product is sold off the shelf. Both are available on request: you ask from a Tunnel account, a person answers, and what you get is agreed with you.

Questions people ask about this

Will this stop phishing?

No, and nothing on this page says it does. Phishing gets an attacker a password or a session. What Flamecloak changes is what that buys them: in the systems you put behind it, the actions that matter still wait for somebody else’s yes, on their own device.

Can Flamecloak protect the sign-in to our admin panel?

Yes, where the sign-in passes through it. Each sign-in then waits for a second person, and can be refused outside its usual hours. Most panels work as they are; some older ones need a small change first, and we check yours with you before you rely on it.

What if the approver’s phone is stolen too?

Ask for more than one person on the actions that matter. With several approvers, one stolen phone cannot approve anything alone, and an approval still needs the phone’s owner to unlock it.

Does it replace our firewall or our sign-in system?

No. Those decide who gets in. Flamecloak and Tunnel t0 decide what happens after that: which actions need a person, when they may happen and how many. Keep both.

Why is it safer when you run it than on our own servers?

Because a guard on the server it guards falls with that server. When we run it, it sits apart from all your machines, so whoever takes one of them cannot switch it off, change its rules or edit the record. If no traffic may pass through anyone else, run it inside your own network, on machines kept apart from the ones it guards.

Will our people notice it?

Only on the actions you chose to hold. Everything else goes through as before. A held action waits for a person, and a screen that waits says so instead of failing.

Start with one door.

Pick the action you would least like a stranger to take, such as the admin sign-in, the export or the payment, and put it behind Flamecloak. Create a Tunnel account and ask for it, and a person will get in touch to set it up with you.