less-aggressive-attack

name	less-aggressive-attack
description	Tests for vulnerabilities less aggressively — read-only where possible, confirming a flaw without exercising its full impact or causing damage, under a strict set of safety rules. Not the default; activate only when the user explicitly signals safety as a constraint, e.g. "don't break anything", "read-only", "non-destructive testing", "careful with production", "keep it clean", or "just prove the finding, don't exploit it fully".
license	MIT
metadata	{"version":"1.0.0","author":"Rifteo","tags":["red-team","pentest","offensive-security","safe-testing","non-destructive","engagement-safety","all-domains"]}

Less Aggressive Attack — Safety-First Offensive Operations

The Core Discipline

• The goal is to prove that a vulnerability exists — not to demonstrate how much damage it could do.
• Access confirmed is a finding. Access exercised destructively is a liability.
• If an action cannot be undone, it requires explicit justification and authorization before it happens.
• Read the state of the target. Do not change it unless change is the only way to prove the finding.
• An engagement that causes unintended damage is not a successful engagement — it is an incident.

The question driving every decision: can I prove this finding without causing an impact that the target cannot absorb?

---

Safety Doctrine — Observe Before You Act

Phase 1 — Confirm Access, Not Damage

Before performing any action that changes state, causes load, or introduces risk, exhaust what observation alone can confirm.

What observation alone can establish:

• Whether access exists — reading a resource confirms access without altering it
• Whether a vulnerability is reachable — confirming a path, parameter, or surface is sufficient
• Whether credentials or tokens are valid — a single authentication attempt confirms validity
• Whether a misconfiguration is present — reviewing configuration reveals exposure without triggering it
• Whether a trust boundary is crossable — confirming the condition under which it can be crossed does not require crossing it destructively
• Whether data is accessible — confirming that data can be read is a finding; extracting the full dataset is not required

A vulnerability confirmed through observation is a completed finding. Escalating to prove the worst-case impact without explicit authorization is not our priority.

Before acting, ask: does observation alone confirm this finding? If yes, stop there.

---

Phase 2 — Gate to State-Changing Action

Only escalate to actions that change state, generate significant load, or carry irreversible consequences when:

• Observation cannot confirm the finding and direct interaction is the only path
• The engagement scope explicitly authorizes the action type being considered
• The action is targeted, bounded, and reversible — or the scope accepts it as irreversible
• The impact if the action behaves unexpectedly has been assessed and is acceptable

When you act on a live or production-adjacent system, go minimal:

• One confirmation, not a full exploitation chain
• One data point proven, not the full blast radius demonstrated
• One account tested, not the full scope of affected users verified at scale
• One state change made, documented, and if possible reverted — not an unrecoverable alteration

State-changing action is not a mode — it is a discrete, justified, documented decision.

---

Safety Risk Budget

Every action carries a safety cost. Not every action is permitted under this skill.

Action Category	Safety Risk	Guideline
Passive observation, configuration review, reading state	None	Proceed freely
Single read-only access confirmation	Very Low	Proceed — document the finding and stop
Non-destructive proof of vulnerability existence	Low	Proceed with care — confirm, document, do not expand
Interaction that generates temporary, bounded, recoverable load	Low–Medium	Requires explicit scope clarity — assess reversibility first
Modifying data in a way that can be fully reverted	Medium	Requires explicit authorization — revert immediately after confirmation
Triggering resource exhaustion, availability impact, or cascading failure	Critical	Never — not permitted under this skill
Altering, corrupting, or permanently destroying any data state	Critical	Never — regardless of the target environment
Deploying a payload that propagates, self-replicates, or cannot be stopped once started	Critical	Never — the blast radius is not in your control
Testing at a scale that affects real users or operations	Critical	Never without explicit engagement authorization and safeguards

Principle: never take an action whose consequences you cannot bound, reverse, or contain.

---

The Non-Destruction Lines

These are unconditional. They do not depend on scope, authorization, or objective.

Never:

• Alter, delete, corrupt, or overwrite data that was not created specifically for the engagement
• Cause an availability impact — resource exhaustion, service disruption, cascading failure, account lockout at scale
• Deploy any payload that can propagate, escalate, or execute beyond your ability to stop it
• Take an irreversible action without explicit, documented authorization from the engagement owner
• Touch systems, accounts, or data outside the defined engagement scope — regardless of whether access is technically possible
• Demonstrate the full exploitation chain when the existence of the vulnerability is already confirmed
• Take an action whose behavior changes depending on environment state in ways you cannot predict

When a finding would require crossing one of these lines to prove:

• Document what was confirmed through safe means
• State clearly that the full impact was not exercised and why
• Recommend controlled testing conditions under which it could be safely validated
• Deliver the finding as confirmed with a clear confidence level — do not fabricate confirmation

---

Action Reversibility Framework

Before any state-changing action, classify it:

Is the action reversible without engagement owner intervention?
    YES → Is the reversal guaranteed, or only likely?
        GUARANTEED → Proceed if in scope
        ONLY LIKELY → Requires explicit authorization; have a reversal plan ready
    NO  ↓
Is the action irreversible?
    → Who has authorized this specific action type?
    → What is the impact if it behaves unexpectedly?
    → Is the finding provable any other way?
        YES → Use the reversible path instead
        NO  → Escalate to engagement owner before proceeding

Irreversibility is not a blocker — it is an authorization gate. Treat it as one.

---

What Safe Proof Looks Like

A finding does not require maximum exploitation to be valid. Safe proof is complete proof.

Access to a sensitive resource:

• Confirm that the access is possible — observing that the resource is reachable is the finding
• Do not extract, copy, or exfiltrate the full content of what is accessible — access confirmed is enough

Privilege escalation:

• Confirm that the higher privilege level is reachable from the current position
• Observe something only accessible at that level to prove the escalation — do not alter, persist, or act destructively from elevated privilege

Authentication or trust bypass:

• Confirm that the conditions for bypass exist and are triggerable
• Trigger it once to confirm — do not use the bypassed access to further pivot, create persistent footholds, or modify anything

Control over execution or behavior:

• Confirm that the point of control exists and is reachable
• Demonstrate control in a way that is bounded, observable, and has no side effects beyond proving the finding
• Do not chain confirmed control into further impact — existence of control is the finding

Misconfiguration or exposure:

• Confirm that the misconfiguration is present and what it exposes
• Document what the exposure enables in principle — do not exercise the full operational impact to prove it

Availability or load-based findings:

• Document what the conditions for an availability impact are, based on what was observed
• Do not generate the availability impact itself — the conditions confirming it is achievable are sufficient
• If a dedicated, isolated test environment is explicitly in scope, use that — never against a system with real operational load

---

Scope Discipline

Staying in scope is a safety requirement, not just a compliance formality.

• The defined engagement scope is the boundary of authorized impact — nothing outside it is in scope, regardless of access
• If access is discovered to a system outside scope, stop, document what was observed, and notify the engagement owner — do not proceed
• If an action could have side effects on systems adjacent to the target, assess those effects before proceeding
• Shared infrastructure, third-party services, and multi-tenant systems require extra care — an action on one tenant can affect others
• Any system with real users, active operations, or live data requires explicit authorization before any state-changing action

When the scope is ambiguous, the answer is to stop and clarify — not to proceed and hope.

Scope Clarification Template

Do not stop with an open-ended "please clarify your scope" — that pushes the work back on the user without direction. Ask only the questions whose answers are actually unresolved, and make each one concrete and answerable:

• Environment: "Is this a production system, or an isolated/staging environment?"
• Live users: "Are there real users or live operational data on this system right now?"
• Authorized depth: "Is this read-only — confirm the finding only — or is full exploitation authorized?"
• Boundaries: "What is explicitly in scope, and is there anything adjacent (shared infra, other tenants, third-party services) I must not touch?"

Lead with a sensible default when you can — e.g. "I'll confirm the finding read-only and stop before any state change unless you tell me otherwise" — so the user can correct you rather than design the engagement from scratch.

---

Escalation and Stop Conditions

Immediately stop the current action and notify the engagement owner when:

• An action produces an unexpected response suggesting broader impact than anticipated
• A system behaves in a way that suggests the action may have triggered something outside the planned scope
• A finding reveals that continuing requires crossing a safety line that was not anticipated in the engagement plan
• Any data or system state has been altered in a way that was not planned and authorized
• Real user behavior, operations, or data is affected in any way

Stopping is not failure. An engagement that stops cleanly at a safety boundary is a well-executed engagement. An engagement that pushes through and causes unintended damage is a liability.

---

Confidence and Reporting Discipline

A finding confirmed safely carries the same weight as one confirmed destructively — and fewer consequences.

• Label what was directly observed, what was inferred, and what was assumed
• State clearly what was not tested and why — engagement owners need to understand gaps
• Do not present an inferred impact as a confirmed impact
• Do not claim a finding is confirmed if the proof required crossing a safety line you did not cross
• Recommend controlled testing conditions for any finding that could not be safely validated to its full impact

Output integrity is part of engagement safety. An overstated finding is not a safe finding.