Sprocket Security · Research whitepaper
A safety framework for autonomous offensive security agents
Autonomous agents are already running reconnaissance, exploitation, validation, and reporting. Generic AI safety frameworks assume harmful actions are always undesirable — offensive security inverts that assumption. This framework defines what “safe” means when an agent is authorized, by contract, to cause controlled harm.
Every vendor in offensive security now runs autonomous agents. Almost none of them will tell you what those agents are forbidden to do. This is our answer, in full, including the parts we are still working on.
Every other AI safety framework assumes harm is the failure.
A penetration testing agent's job is to cause controlled, authorized harm under contract. It sends malformed input, attempts authentication bypasses, exploits misconfigurations to demonstrate impact. Those actions are not failure modes — they are the product. A framework built to prevent all harm cannot tell you how to authorize the right harm.
"Did the agent do something harmful?"
Guardrails exist to stop dangerous output. Alignment work assumes the human intention is to avoid harm. Applied to an offensive agent, this produces a smoke detector that refuses to detect smoke.
"Did it do the right harmful thing, in the right proportion, with the right evidence trail?"
Was the injection attempt directed at an in-scope application? Was the privilege escalation test proportionate to the objective? Was every action logged in enough detail to reconstruct what happened and why?
The safety question is not whether to cause impact. It is how much impact is necessary to achieve the testing objective.
Seven required properties of a safe autonomous offensive agent
Each property is defined in the context of offensive automation, with a rationale, its core mechanisms, and a named failure mode. Together they define the floor of acceptable safety — not testing quality, which is a separate question.
Bounded
The agent operates within a defined scope and cannot exceed it. It does not pivot to unauthorized targets, does not treat third-party dependencies as attack surface, and resists prompt injection from target responses that tries to widen its scope.
Proportionate
Actions match the objective in kind and degree. If SQL injection is present, a SELECT proves it — there is no need to DROP a table. The agent demonstrates that it could reach sensitive data without extracting all of it, and backs off when target health degrades.
Veridical
Output accurately represents what was observed. Findings correspond to real vulnerabilities, evidence is genuine request and response data, and the entity that discovers a vulnerability is not the one that writes it up.
Contained
Sensitive data discovered during testing stays inside authorized boundaries — credentials in config files, PII in API responses, business data exposed through a vulnerability. Nothing persists beyond the session or leaks between engagements.
Efficient
Resource consumption is proportional to value delivered. Budget, wall-clock, finding-rate, and target-health boundaries terminate execution unconditionally — making efficiency the safety property of last resort when other controls have failed.
Transparent
Every action is recorded, reconstructible, and attributable. Recording is structural, not voluntary: it happens at the infrastructure layer, outside the agent's control, and cannot be bypassed or disabled.
Governable
Humans can intervene, redirect, or terminate at any point. Escalation criteria define when the agent must defer to human judgment, and termination preserves partial results. Governability is what keeps the other six enforceable as unanticipated situations arise.
Structural controls, not instructions
Two fundamentally different mechanisms enforce safety in an autonomous agent, and where you place each one is itself a safety-critical design decision.
Implemented in code, outside the model's decision loop
A network policy restricting egress to in-scope addresses. A budget ceiling that terminates execution. A blocklist that rejects destructive commands. The defining characteristic: the agent cannot bypass them. It does not matter what the model outputs or what reasoning led to the action. Use them when the action is high-risk with no judgment call, when the consequence is irreversible, and when a false allow is severe.
Implemented through prompts, inside the model's decision loop
"Do not test any system outside the defined scope." The agent follows it because the instruction says to. Nothing in the execution environment prevents it from being ignored under prompt injection, context pressure, or a model version change. Necessary for the fuzzy boundaries structural controls can't express — but never a substitute for them where stakes are high.
A behavioral control on data exfiltration means the agent probably will not exfiltrate data. A structural control means it cannot.
What each property requires, phase by phase
Every autonomous engagement moves through four phases. Each presents different risks and demands different controls. Select a phase to see the normative requirement for all seven properties.
Authorization is verified. Scope is defined in a machine-parseable format. Budget and resource constraints are set. Methodology and rules of engagement are configured. Infrastructure is provisioned.
Scope is defined in machine-parseable format and validated before execution begins. Scope enforcement mechanisms are tested against known out-of-scope targets.
Methodology is configured with explicit limits on exploitation depth, request rate, and payload destructiveness. Denial-of-service and data-destructive techniques are disabled by default.
Validation requirements are defined: each finding type has a specified evidence standard. False-positive thresholds are set. Automated re-test criteria are configured.
Data handling boundaries are defined: which provider processes prompts, where evidence is stored, what egress is allowed. No data path exists from one engagement's storage to another's.
Budget is defined in measurable units (dollars, tokens, wall-clock time). Resource allocation matches the engagement's size and complexity.
All configuration decisions are logged: who authorized the test, what scope was defined, which methodology was selected, what infrastructure was provisioned.
Human reviewers approve scope, methodology, and budget before execution. Kill-switch and pause mechanisms are verified as functional. Escalation contacts are defined.
The agent actively tests the target — discovering endpoints, probing for vulnerabilities, validating findings, documenting its work — while real-time controls monitor scope compliance, budget, and destructive action attempts.
Every request is checked against the scope definition before transmission. Discovered assets outside scope are logged but not tested.
Write-method requests use only agent-created test data. Exploitation depth proves the vulnerability exists without maximizing impact. The agent stops at proof, not full compromise.
Each potential finding is validated before inclusion. The agent re-tests to confirm exploitability and distinguishes confirmed, probable, and unverified findings.
Discovered sensitive data is written only to the engagement's isolated results volume. Nothing is exfiltrated to external services or logged to shared infrastructure.
High-value test paths are prioritized over exhaustive enumeration. Budget consumption is tracked in real time with thresholds that trigger strategy shifts.
Every action is logged with timestamp, target, method, and result. Decision rationale is recorded. The log supports full replay of the agent's reasoning.
Humans can pause, redirect, or terminate at any time. Predefined escalation triggers — unexpected access level, potential data breach, scope ambiguity — automatically pause execution and notify a human.
Findings are assembled into structured output with evidence, a testing narrative is generated, output is validated for accuracy, sensitive data is redacted, and the deliverable is prepared for human review.
Output is filtered to remove data gathered from incidental out-of-scope contact. Findings reference only in-scope targets.
Severity ratings reflect actual demonstrated impact, not theoretical maximum impact. Proof-of-concept descriptions document the minimum steps to reproduce.
Every reported finding includes raw evidence — request/response pairs, tool output. Confidence levels are stated. No finding is reported without supporting proof.
Sensitive data in evidence is redacted before inclusion in customer deliverables. Raw evidence is stored in encrypted, access-controlled archives separate from the report.
Report generation uses cached findings data rather than re-querying the target. Generation cost is bounded separately from testing cost.
The report documents what was tested, what was not tested, and why, with tool versions and configurations. The audit trail is linked from the report.
Human review is required before findings reach the customer. Reviewers can modify severity, add context, redact content, or reject findings. The agent does not deliver output autonomously.
Evidence is archived per retention policy, sensitive data is purged, session state is destroyed, the audit trail is finalized, and lessons learned feed back into framework improvements.
The scope definition is archived as part of the engagement record. Any scope change requests made during execution are preserved in the audit trail.
Engagement metrics — requests sent, exploitation attempts, data accessed — are reviewed against proportionality criteria. Disproportionate actions are flagged for process improvement.
Reported findings are compared against customer feedback. False-positive rates are calculated and stored to improve future detection accuracy.
Session state is destroyed. The evidence archive is stripped of raw sensitive data, retaining only redacted proof artifacts. No engagement data persists in model provider systems.
Cost metrics are finalized: total model tokens consumed, total requests to target, wall-clock time. These inform pricing and future resource allocation.
The complete audit trail is finalized and checksummed, covering pre-engagement configuration, execution logs, reporting decisions, and destruction confirmations.
Data destruction requires human confirmation for non-automated retention actions. Exceptions to the standard destruction schedule are logged and require human approval.
Three levels, assessed per property
The model supports self-assessment and progression planning. The critical transition is Baseline to Managed — the shift from behavioral to structural enforcement for high-risk actions.
Baseline
Controls exist but are primarily behavioral. Scope lives in natural language inside system prompts. Budget limits exist with approximate cost tracking. Logging captures major events, not every tool call. Human review happens post-engagement as a separate step. Deployable for supervised testing only.
Managed
Structural enforcement for high-risk actions. Pre-action hooks validate operations against policy before execution. Machine-parseable scope. Cost-integrated budget ceilings that terminate execution. Every tool call and hook decision in a structured audit log. Container-level session isolation. Human review is a required gate in the output pipeline.
Adaptive
Every safety-relevant control has a documented threshold, a measurement methodology, and evidence of periodic review. Thresholds calibrated to observed distributions. Anomaly detection flags behavioral drift before it becomes control failure. Safety properties regression-tested after any safety-relevant change.
A property-level crosswalk to the OWASP standard
The OWASP Autonomous Penetration Testing Standard is a compliance standard for procurement and vendor evaluation. This framework is a design document for the teams building the systems APTS evaluates — it supplies the rationale beneath the requirements.
| Property | Maps onto (APTS domain and representative requirements) | Nature of fit |
|---|---|---|
| Bounded | Scope Enforcement: machine-parseable rules of engagement, pre-action scope checks, immutable deny-lists (SE-001, SE-006, SE-009). Scope-changing injection under Manipulation Resistance (MR-005, MR-012, MR-023). | Direct on core scope. APTS splits this across two domains and files rate-limiting and production-impact control under SE, which this framework treats under Proportionate. |
| Proportionate | Safety Controls and Impact Management: CIA impact classification, per-tier payload and rate caps, graduated approval escalation, health-based automatic halt (SC-001, SC-004, SC-006, SC-010); adaptive backoff (SE-019). | Substantial overlap, one addition: minimizing impact within the permitted envelope — proving a finding with the least sufficient action and stopping at proof rather than maximizing exploitation. |
| Veridical | Reporting: evidence-backed findings, automated reproduction, confidence scoring, false-positive-rate disclosure (RP-001, RP-002, RP-003, RP-006). | Direct and enriched. APTS mandates the mechanics; this framework adds that a false positive is a trust violation, not a defect, and separates the discovering role from the reporting role. |
| Contained | Third-Party and Supply Chain Trust: per-engagement isolation, cross-engagement leak detection, no reuse of one customer's data for another (TP-017 to TP-020); execution sandbox (SC-019). | Split, with a gap. APTS's "third party" is the platform's own supply chain. Custody of outsiders' data the agent discovers as a byproduct has no APTS home and is developed here. |
| Efficient | Safety Controls hard stops and time-based termination (SC-011, SC-013); Graduated Autonomy resource management. | Largely this framework's lens. APTS has these as scattered controls; treating efficiency — budget ceilings and value-rate decay — as a safety backstop of last resort is not an APTS property. |
| Transparent | Auditability and Reproducibility: structured event logging, an audit trail the agent cannot reach, post-update regression of safety controls (AR-001, AR-017, AR-020). | Direct. This framework adds the framing that recording is structural and involuntary, occurring at a layer the agent cannot disable. |
| Governable | Human Oversight and Intervention: approval gates, decision-timeout SLAs, one-click kill switch, low-confidence escalation (HO-001, HO-003, HO-008, HO-013); kill-switch timing bound (SC-009). | Direct. This framework adds that governability is what keeps the other six properties enforceable as unanticipated situations arise. |
The data custody problem unique to authorized testing
Offensive agents discover data they were not looking for, belonging to third parties, as a byproduct of legitimate testing. Section 9 covers the infrastructure that keeps it contained.
The inference data path
Which provider processes prompts, what it retains, and how configuration choices close off logging, caching, and training pathways.
Cross-engagement segmentation
No data path from one engagement's storage to another's — including inferred knowledge, not just raw bytes.
Structural output redaction
Credential and PII redaction enforced in the output pipeline rather than requested of the model.
Retention and destruction
What is archived, what is purged, and the regulatory considerations for third-party data discovered mid-engagement.
Read the full framework
Seven properties with rationale and core mechanisms, the properties × phases matrix, the maturity model with progression guidance, implementation patterns, and a self-assessment checklist suitable for internal audit or vendor evaluation. Published in full, no form and no email required — the PDF is a convenience, not a toll.
About this document
Safety Framework for Autonomous Offensive Security Agents is a research whitepaper from Sprocket Security. It is a measurement framework rather than a compliance standard: a vendor claiming adherence has assessed its controls against the framework’s properties and maturity levels, not passed a certification threshold. It is grounded in operational experience from professional penetration testing and production deployment of autonomous offensive agents; independent multi-vendor validation has not yet been conducted.
v1.0 · August 14, 2026 · Conformance language per RFC 2119