Piscium SecurityPISCIUMSECURITY
Testing Safety Posture

What stops us from breaking your environment.

Autonomous validation only earns its place if it is safe to point at production. This is the engineering that constrains Radius on a live estate, published so you can assess it before you authorise anything.

Always on

The safety interceptor is not a module.

It cannot be switched off for a faster run, a bigger scope, or a more impressive demo. Every agent tool call passes through all three layers, every time.

The safety interceptor

Three layers of validation, in order, before any action reaches your estate.

01

Hard-coded blocklist

Eighteen non-bypassable patterns that no configuration can switch off — destructive filesystem operations, fork bombs, reverse shells, crypto miners, and anything that would shut a host down.

Cannot be disabled, by us or by you

02

Custom blocklist

Your own patterns, scoped to your tenant and managed by your administrators. Plain text or regular expressions, each rule individually enabled or disabled.

Yours to control

03

Rules of engagement

Per-asset policy: which addresses and ranges are in scope, which ports, which scan types, which exploits are permitted, and the time windows and blackout dates the run must respect.

Agreed before the engagement starts

If any layer blocks a call, the call does not run and the block is recorded with the layer responsible for it.

Every decision is written down

Not only the blocked ones. Each entry records what was attempted, what was decided, why, and — critically — a snapshot of the rules of engagement in force at that moment.

That last field is what makes the trail usable as evidence months later. You are not asked to trust that the policy was correct at the time; the policy is captured alongside the decision it governed.

Recorded per decision

The action
Which tool was invoked, and with what input.
The decision
Allowed or blocked, and by which layer.
The reason
The rule or boundary that produced the outcome.
The policy in force
A snapshot of the rules of engagement at that instant.

Measured against published doctrine

Rather than asking you to accept our own account of what responsible testing means, we hold the platform to the boundaries set out in the US GSA’s penetration testing guidance, CIO-IT Security-11-51 Rev 7:

  • No action outside the agreed rules-of-engagement boundary.
  • No persistence left behind beyond the testing window.
  • No new vulnerabilities introduced into the target environment.
  • No modification of the target's logs.

To be precise about what this is. CIO-IT Security-11-51 is a recognisable and publicly checkable template for safe testing conduct. It is not a certification, we are not audited against it, and it carries no regulatory authority in Latin America. We cite it because it lets you hold us to somebody else’s definition of responsible behaviour rather than ours.

Questions before you authorise a test?

Send them. We would rather answer a hard security question early than have it surface after the rules of engagement are signed.

Talk to us