AI agent security · For security teams and CISOs
The model may agree. The action still requires current human authority.
Regulayer™ is a runtime authorization check for AI agent actions. It runs outside the agent, in front of your systems. Before an action takes effect, it confirms that a named person’s current authority covers it. If it does not, the action does not run. Every decision, allowed or stopped, is signed and can be verified offline.
2 ms median, 3 ms p95, across 158 live decisions · Fail closed: if the check cannot complete, the action does not run · Runs inside your environment, with no cloud service of ours · Connects as a tool wrapper, a gateway, or over MCP · Technical overview · Your platform
Runs inside your environment. Your data does not leave it.
What CISOs report
Fewer than half can say what their agents may do.
Competitive landscape · For security teams
The security stack decides what the agent may do. Regulayer™ proves who currently authorizes it.
Identity providers issue identities; Regulayer™ accepts their withdrawals. Each layer below already runs in your stack and answers its own question. Regulayer™ adds the one that sits at the moment of effect.
Categories, not vendors. Each layer answers its own question; Regulayer™ works alongside them.
The film · An AI agent in production
The agent found a token. Who allowed it?
In April 2026 a coding agent deleted a production database and its backups in nine seconds, using a token it found, as the founder reported it. Watch the same kind of work run through the Regulayer™ airlock. Each step shows the control it supplies evidence toward.
The agent works a staging ticket under Dana Ortiz’s authority.
Press Play. Every step is a sample; the frameworks on the right are real.
The AI
Operations agentThe airlock
Regulayer™ · Mathematical. Outside the AI.- Named person: Dana Ortiz
- Authority current, this moment
- This exact action covered
- Record sealed first
Your systems
Dana Ortiz, Platform LeadWhat each framework asks, and the record that answers it
The instruction may reach the model. If the named person’s authority does not cover the action, it does not run.
Each action checked against a named person’s current authority just before it runs, outside the agent.
Every allow and every stop, signed as it happens, exported as OCSF 1.9 to your SIEM, enabled in a pilot.
What was proposed, what was stopped, and when, signed as it happens, so the sequence is ready when the disclosure clock starts.
A named person who can stop it, and a record that they did.
Now you try
Talk the agent into anything. Only what a named person authorized reaches your systems.
This operations agent works under Dana Ortiz’s authority: restart services and scale staging. Pressure it, hide an instruction, pose as the CEO. We built it to give in every time. Regulayer™ checks each action it proposes against her current authority before it runs.
Regulayer™ airlock
Now the second act. Withdraw Dana Ortiz’s authority, then send the ordinary request again.
The sealed record
Take a real signed record home: download one and check it in the open verifier, without us.
The model may agree. The action still requires current human authority.
What is real here, and what is not
Real. The rule: an action outside the named person’s current authority does not take effect, and every outcome is recorded. Alter an entry and verification fails.
Sample. The company, the agent and Dana Ortiz are samples, and the agent agrees on purpose. Nothing reaches a real system. In a live demo, the engine runs against your own scenario.
In your team’s words
Pick a word. See what it means here.
The instruction can still reach the model. Without a named person’s current authority, the action does not take effect.
From the Consequence Library
Where an agent acted, and what followed.
Why now
Why now, in dates.
A pilot for security teams
A short pilot, one workflow, your own agents.
The workflow
- Privileged actions: credential resets, group changes, access grants.
- Each one checked against a named person’s current authority before it runs.
- A withdrawal from your identity provider stops queued privileged actions.
Success looks like
- Every privileged action carries a named authority.
- A withdrawal stops a queued action, shown to your team.
- Records land in your SIEM without custom parsing.
- Added time per action measured against a budget you set.
The pilot is paid, and the fee is credited back in the first quarter after the licence is signed.
For your security architect
The detail, when you want it.
Where it sits in your architecture
| Concern | How it is handled |
|---|---|
| Zero trust | An enforcement point, in the terms of NIST SP 800-207. A named person sets the authority. The AI proposes. Regulayer™ holds the action to that authority, and it runs only if the authority covers it. |
| Placement | In the path, before a consequential action takes effect: a tool call, an API call, a write, a payment. Outside the model and outside the agent, so the agent cannot switch it off. |
| SIEM and SOC | Records export as OCSF 1.9, so every allow, hold and stop reaches the tools your SOC already reads. Enabled in a pilot on request, with the SSF, CAEP and MCP connections below. |
| Identity | An identity provider can withdraw a person’s authority through SSF and CAEP security events: withdraw only, never grant. |
| Agent platforms | A read-only MCP server gives status, record export and verification. Agent tool wrappers and a fail-closed gateway put the check in front of the tools. |
| Failure mode | Fail closed. If the check cannot complete, the action holds and the record says stopped or unknown, never a success it cannot show. A stop stays latched until a named person re-arms it, and the re-arm is its own decision. |
| Isolation | It can run on separate compute from the AI it checks (Class 3 in the Cleanroom Standard): its own node or a discrete controller, with no shared memory, no shared process and no shared storage. |
| Record integrity | One signed entry per check, allowed or refused. Change one character and verification fails. Anyone can verify offline with the open verifier, with no account and no call to Regulayer™. |
| Data residency | Each record carries the outcome, not your data. Payloads stay inside your boundary, behind your own network and access controls. |
The frameworks it supplies evidence toward
| The framework | What it asks | What Regulayer™ supplies |
|---|---|---|
| Agentic AI guidance | ||
| Careful adoption of agentic AI servicesCISA, NSA, ASD’s ACSC, Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK, 1 May 2026 · The guidance | Prevent agents from executing high-impact actions without prior human approval. Human-in-the-loop checkpoints where the cost of error is high. Identity and authorisation verified continuously at runtime, through a centralised policy decision point. | A named person’s authority over high-impact actions, checked at runtime before each one takes effect, outside the agent, with every outcome sealed. |
| Security frameworks | ||
| NIST Cybersecurity Framework 2.0PR.AA, PR.PS-04, DE.CM · NIST text | Access permissions and authorizations defined, managed, enforced and reviewed, with least privilege and separation of duties. Log records generated and made available for continuous monitoring. | Each AI action checked against the authority approved for it before it runs, and a signed log record of every outcome, allowed or refused. |
| NIST SP 800-207, Zero Trust ArchitectureNIST text | Access decided per request by a policy decision point and enforced by a policy enforcement point, with no implicit trust. | An enforcement point in front of every consequential action an agent proposes, holding it to the authority a named person set. |
| ISO/IEC 27001:2022Annex A 5.15, 8.15, 8.16 | Access control, logging, and monitoring of networks, systems and applications for anomalous behaviour. | Operation-time evidence for each control: the action, the named person whose authority covered it, and the outcome. |
| AICPA SOC 2CC6.1, CC7.2, CC7.3 | Logical access controls, monitoring of system components for anomalies, and evaluation of security events. | A signed record that the control operated, action by action, that your auditor can check. |
| Incident reporting | ||
| EU NIS2, Directive (EU) 2022/2555, Articles 21 and 23EUR-Lex text | Risk-management measures including incident handling and access control policies. An early warning within 24 hours of a significant incident, a notification within 72 hours, and a final report within one month. | A time-stamped, tamper-evident record of what the agent proposed, what was stopped and when, ready when the clock starts. |
| SEC Form 8-K Item 1.05Release 33-11216 · SEC text | Public companies disclose a material cybersecurity incident within four business days of determining it is material. | The sequence of an AI-driven event, sealed as it happened, to support the materiality determination. |
| AI application security | ||
| OWASP Top 10 for LLM Applications 2025, LLM06 Excessive AgencyOWASP text | Root causes: excessive functionality, excessive permissions, excessive autonomy. Mitigation: human-in-the-loop control, so a human approves high-impact actions before they are taken. | A named person sets the authority for high-impact actions. Each action is checked against it before it runs. |
Regulayer™ supplies the evidence. Your auditor, regulator or court makes the determination.
Your data stays where it is
- Runs on your infrastructure. On premises, on your own servers, or in a sandbox for a pilot.
- Your data does not leave it. Payloads stay behind your own network and access controls.
- No Regulayer™ cloud service is required.
- Model-agnostic. Change the model, and the check stays where it is.
- Verify offline. Anyone holding a record can check it, with no account and no call to Regulayer™.
Learning Center
For security teams.
See it live
See it live, on your own scenario.
Regulayer™ supplies the evidence. Your auditor, regulator, insurer or court makes the determination. Patent pending.