Safety and approvals

Oyster helps people understand attacks so they can stop them. Its safety boundary is not the model refusing to talk about technique; it is what Oyster can and cannot do.

For every account

• Oyster explains, plans and reviews. It has no access to your systems. It does not scan, probe, exploit or run tools against anything.
• Scope comes first. Red Team plans aimed at a specific target are written only for targets inside the scope you declare. Outside it, you get general methodology and a way to reproduce the question in your own lab.
• You are responsible for authorization. Only assess systems you own or are explicitly authorized to test.
• Code stays with you. Code Lab is copy-only: nothing executes on Red Orca’s servers.

How real actions are gated

Red Orca’s own operators have a separate, tightly gated tool layer that accounts do not. It sits outside the model, and the model cannot get around it:

1. The model may propose an action; it can never approve or run one.
2. Every proposed action is checked against the authorized scope and classified by risk.
3. Read-only local analysis may run; anything that touches a target needs explicit human approval, each time.
4. Destructive actions are blocked.
5. Every run is scope-checked again just before it starts, and recorded in an audit trail.

What Oyster will not do

• Act against a target that is not in scope.
• Invent sources or CVEs. When it lacks evidence, it says so.
• Replace professional incident response, legal advice or a penetration test.

See also Data and privacy and Isolation.