Escalate what you cannot safely solve

1651. Lesson identity

Module

4.6 — Security and abuse

Lesson

Escalate what you cannot safely solve

Academic type

Workflow

Schema type

Mixed

Order

Lesson 2 in the module

Estimated time

35–50 minutes, including practice

1652. Learning objective

After this lesson, you can write an initial response plan that assigns a severity level, identifies safe containment, preserves useful evidence, and escalates unresolved risk without exposing sensitive information.

1653. Why this matters

Naming an abuse surface is only the first response decision. The next decision is what to do when the available evidence is incomplete, the harm may continue, or the proposed fix could create a larger problem. A disciplined response plan prevents two opposite failures: ignoring a serious issue and taking an unsafe action without enough authority or context. In an AI-assisted workflow, the plan also separates information that can be shared for analysis from information that must remain protected.

1654. Prior knowledge

You should already be able to use the previous lesson's abuse-surface questions: what can be manipulated, who has authority, what benefit misuse provides, and who loses value or control. You should also be able to distinguish an observed fact from an assumption. This lesson does not require you to make a code change or access production systems.

1655. Core concept

A response plan is a sequence of bounded decisions, not a promise to fix everything immediately. It should answer four questions:

1. How severe is the current risk?
2. What safe action can reduce harm now?
3. What evidence must be preserved before it disappears or is altered?
4. Who must decide or assist when the problem exceeds your authority, certainty, or safe operating procedure?

Severity is not the same as inconvenience. Consider the scale of harm, whether the abuse is ongoing, how easily it can be repeated, how many players or systems may be affected, and whether the response itself could destroy evidence or increase exposure.

Containment is a temporary risk-reduction action. It is not automatically the final fix. Examples include disabling a vulnerable action, limiting a feature to a controlled test environment, pausing a reward path, or applying a narrow account or session restriction when the authority and criteria are clear. Do not invent a containment action that you are not authorized or technically able to perform.

Evidence preservation means recording enough information to support investigation without copying secrets into ordinary notes, chat, AI tools, or repositories. Preserve timestamps, the affected build or version, reproducible steps at a safe level of detail, observable behavior, scope, and relevant identifiers with sensitive values hidden or replaced by approved references. Do not copy or independently gather passwords, authentication tokens, private keys, full payment data, or unnecessary personal information into your response plan. If restricted source evidence may matter, preserve it only through an approved evidence system when you are authorized to do so, or refer the matter to an authorized responder without exposing the value.

Escalation is appropriate when the impact is high, the abuse may be active, evidence is incomplete, the proposed action is irreversible, or the issue crosses an ownership or security boundary. Escalation is not a failure to solve the problem. It is a controlled transfer of decision-making to someone with the required authority or expertise.

1656. Mental model

Use the S-C-E-E response frame:

Use provisional language when certainty is low. For example: “Observed: the reward animation appeared twice. Confirmed: the balance increased once. Unknown: whether the duplicate presentation can be used to trigger a second grant.” This preserves accuracy while still allowing a timely response.

A useful severity statement has this form:

Severity: [low / medium / high / critical, or the available local scale]. Reason: [impact] may be [ongoing or repeatable], affecting [scope]. Confidence: [high / medium / low] because [evidence boundary].

A useful escalation request has this form:

Request: Please review [issue summary with sensitive details removed]. Risk: [provisional severity and likely harm]. Containment status: [action taken or “not yet contained”]. Evidence available: [safe facts and approved references]. Decision needed: [specific authority or technical judgment]. Urgency: [time-bound reason].

1657. Concrete example

Imagine a fictional game build in which a player can repeatedly submit the same reward confirmation before the first request finishes. You observe a duplicate confirmation message, but you have not verified whether the underlying reward was granted twice.

A weak response says: “The reward system is exploitable. Delete the affected records.” This overstates the evidence and proposes an irreversible action that may destroy useful history.

A proportionate initial plan says:

• Severity: Provisional medium severity. The behavior may allow repeatable value gain, but duplicate granting is not yet confirmed. If the action works outside a test environment or affects many accounts, reassess upward.
• Containment: Ask the responsible owner whether the confirmation path can be temporarily disabled or restricted in the affected test context. Do not change live behavior without authorization.
• Evidence: Record the build identifier, approximate test time, sequence of visible actions, and the observed result. Use an anonymized test-account reference rather than a name, email address, token, or full account record.
• Escalation: Send the summary with sensitive details removed to the system owner or security contact, requesting verification of the grant operation and guidance on whether additional containment is authorized.

The plan does not claim that an exploit is proven. It reduces uncertainty, protects evidence, and moves the decision to the role that can safely investigate or act.

1658. AI-native workflow

AI can help structure a response plan, but it should not receive secrets or become the authority for severity decisions. Use this bounded workflow:

1. Write the observed facts yourself before asking for assistance.
2. Replace names, account identifiers, URLs, tokens, keys, internal hostnames, and other sensitive values with placeholders.
3. Ask the AI to check whether the plan distinguishes facts, assumptions, containment, evidence, and escalation.
4. Compare the draft against your evidence and local authority boundaries.
5. Remove unsupported claims and confirm the final recipient through an approved channel.

A safe prompt might be:

“Review this incident outline, from which sensitive details have been removed, for missing response-plan fields. Do not infer unobserved impact. Separate observed facts from hypotheses and suggest questions for the system owner.”

Do not paste credentials, private logs, personal data, or raw production traces merely to make the draft more detailed. If you cannot determine whether information is safe to share, treat it as sensitive and escalate through the approved process instead.

1659. Git workflow

Git's role in this workflow is controlled review, not implementation. Security-sensitive changes must be reviewed through an access-controlled repository and by the role authorized to assess the relevant risk. Review the proposed diff for changes to authority checks, account boundaries, validation, reward or state transitions, logging, and other security-sensitive behavior before it is accepted.

Do not commit secrets or sensitive evidence. Never place passwords, authentication tokens, private keys, raw production logs, personal data, or incident material containing exposed sensitive values in the repository. Keep evidence in the approved restricted channel, or commit only references with sensitive details removed when repository policy explicitly permits it. If an AI assistant summarizes a diff or review note from which sensitive details have been removed, verify the result against the actual change and repository access rules. This lesson asks you to prepare and escalate a review; it does not ask you to implement, commit, or merge a fix.

1660. Common mistake

The most common mistake is treating escalation as a fully formed diagnosis. Learners often wait until they can prove the entire failure, or they send a dramatic claim with raw evidence attached. Both approaches are unsafe. Escalation can be an early, precise request for authority or investigation: state what was observed, what remains unknown, what harm might continue, what safe containment is available, and what decision is needed.

1661. Guided practice

Create an initial response plan for this fictional scenario:

During testing, a player can trigger a dialogue confirmation twice by repeating an input before the first response appears. You do not know whether the second confirmation changes game state. The test notes include a player name and a session token, but neither is needed for the first escalation.

Write 150–250 words using the S-C-E-E frame. Your plan must:

1. Assign a provisional severity and explain the uncertainty.
2. Propose one reversible containment action, or explicitly state why none is authorized yet.
3. List the minimum evidence to preserve and identify which sensitive details must be hidden or replaced by references.
4. Name the role that should receive the escalation and state the decision or investigation you are requesting.
5. Avoid including the player name, session token, credentials, or invented impact.

Then revise your plan once. Remove any claim that is not supported by the scenario and replace any sensitive value with a generic reference.

1662. Validation / evidence

Your response plan is acceptable when a reviewer can point to all of the following without guessing:

• A provisional severity tied to impact, scope, repeatability, and confidence.
• A containment proposal that is reversible or clearly marked as requiring authorization.
• A minimal evidence list that preserves investigation value without exposing sensitive information.
• A specific escalation recipient role and a concrete decision or investigation request.
• Clear separation between observed facts, unknowns, and hypotheses.

If the reviewer cannot tell what action is authorized, what remains unknown, or who owns the next decision, revise the plan before sending it.

1663. Key takeaways

• Severity should reflect potential harm and uncertainty, not emotional intensity.
• Containment reduces ongoing risk; it is not automatically the permanent fix.
• Preserve minimal, useful evidence without copying secrets or unnecessary personal information into ordinary response materials.
• Refer restricted source evidence to an authorized responder or preserve it only through an approved evidence system when authorized.
• Escalate when authority, evidence, impact, or safe operating limits are exceeded.
• A good escalation request transfers a specific decision, not an unsupported conclusion.

1664. Next lesson

Continue to 4.7 — Ethical monetization.

1665. Knowledge check