Platform
Autonomous does not mean unsupervised
The first question any security lead asks about an autonomous agent is whether it can break production, and who authorised it to try. Here are both answers.
Scope
The estate is declared before anything runs
Revelion does not discover its way into systems you did not authorise. Scope is an input to the mission, not a boundary it works out along the way.
- Targets are explicit
- Hosts, domains and ranges are declared up front. Anything outside the declaration is out of bounds.
- Exclusions are honoured
- Systems you name as off-limits stay off-limits, including hosts discovered mid-mission.
- Scope is recorded with the run
- Every mission carries the scope it executed against, so the record is auditable afterwards.
Control
Guardrails are enforced in the engine, not waited on
Revelion is autonomous by design, so its limits cannot depend on somebody being at a screen to approve each step. What the agent may and may not do is constrained in code, and you extend those constraints with your own.
- Code-level guardrails
- Destructive and state-changing actions are refused by the engine itself unless the scope you declared permits them. They are not queued for someone to wave through.
- Your own guardrails and context
- Layer your own constraints, exclusions and operating context on top of the built-in ones, so a mission runs to your rules of engagement rather than to a generic default.
- Steerable mid-mission
- Redirect the engagement while it is running rather than waiting for a report to disagree with.
- Destructive actions are opt-in
- Anything with the potential to disrupt a service is off unless the declared scope enables it, rather than being approved in the moment.
- Manual mode, if you want it
- A step-by-step mode exists for teams who want to drive an engagement directly. It is an option, not how Revelion normally runs.
- Full action log
- Every action the agent took is recorded, so the engagement can be reconstructed later.
Authorisation
Testing runs against a Letter of Authorisation
Penetration testing without documented authorisation is difficult to defend, whether the question comes from your board, your client, or a regulator. It matters more, not less, when testing recurs this often, because there is no single engagement window to point at.
Revelion publishes a Letter of Authorisation template covering the estate in scope, the window, the permitted actions and the named parties. For MSPs testing on behalf of clients, it establishes that the client authorised the work rather than the provider assuming it.
The authorisation record sits alongside the mission history, so the question "who approved this, and when" has an answer that does not depend on somebody remembering.
Production safety
Designed for estates that cannot go down
Most environments worth testing are environments in use. The controls that make that safe are built in rather than bolted on.
- Rate and concurrency limits
- Testing intensity is bounded so a mission does not behave like a denial-of-service attempt.
- Proof over persistence
- The agent demonstrates access and stops. It does not establish footholds or leave artefacts behind.
- Reversible by default
- Actions that would change state are refused unless the declared scope permits them.
- Scheduling windows
- Run against production inside the windows you nominate, not whenever a schedule fires.
- Immediate stop
- A mission can be halted at any point, and stops without leaving work half-completed.
- Clean-up is part of the run
- Test data created during a mission is identified so it can be removed.
Read the authorisation template before you scope anything.
Talk to us about scope