LumynFDE School

Mission 07 · Build and prove

Secure consequential actions

Keep model-visible reads and real-world effects behind trusted identity, policy, approval, duplicate-safety, and verification boundaries.

Self-directed lesson

Field question
What must trusted software recheck immediately before a consequential effect?
Working artifact
Tool contract + threat tests
Effort
2 hours

You will learn

  • Why tool descriptions and model plans never grant authorization.
  • How tenant, identity, scope, approval freshness, egress, and credentials are enforced.
  • How prompt injection, duplicate effects, partial failure, and stale approval become negative tests.

Field practice

  1. Trace one effect from untrusted input to the system of record.
  2. Define the typed tool contract and all service-enforced preconditions.
  3. Test denial, replay, cross-tenant access, stale approval, partial failure, and readback mismatch.

Before you begin

Bring one model-visible capability or consequential effect, its caller identity, tenant boundary, approval policy, and system of record.

Learning objectives

  • Specify a narrow typed contract for each read and effect capability.
  • Enforce identity, tenant, scope, policy, approval freshness, credentials, egress, and duplicate safety in trusted software.
  • Test injection, denial, replay, cross-tenant access, partial failure, and readback mismatch.

Core lesson

What you need to know

01

Assume every model-visible string is untrusted

User input, retrieved pages, documents, tool output, prior messages, and model plans can contain instructions. They may provide evidence but never policy or authorization. Keep secrets out of prompts, scope reads by tenant and purpose, and minimize the content exposed to the model.

Tool descriptions explain capability shape; they do not grant permission. Trusted services must authenticate the caller and recheck tenant, object scope, policy revision, approval freshness, and capability version immediately before a consequential effect.

02

Make effects duplicate-safe and verifiable

Each write needs a stable idempotency key, explicit preconditions, bounded parameters, timeout behavior, and a source-of-truth readback. Handle the uncertain state where the request timed out after the effect may have occurred. Retry only when the contract can prove that duplication is safe.

Keep credentials and egress at the tool boundary. The model should receive opaque references or minimum necessary data, not reusable secrets. Log authorization basis and effect result without leaking restricted content.

03

Test the boundary negatively

Positive tests prove only that allowed use works. Security evidence must show that stale approval, wrong tenant, replay, parameter expansion, prompt injection, missing readback, and partial failure are denied, contained, or recoverable.

Worked field case

Writing a correction recommendation

Candidate rec-0.4.2 can write a recommendation to the claims workbench but cannot submit a claim.

Evidence available

  • The model has no submission capability and never receives the specialist credential.
  • The duplicate-recommendation test fails, so the current recommendation-write boundary is not release-ready.
  • Proposed future requirement: a separate submission service would need fresh claim- and revision-scoped specialist approval plus source-of-truth readback; this behavior is not evidence for the current candidate.

Reasoning path

  1. Use a narrow recommendation-write contract with tenant and case scope.
  2. Require a stable idempotency key, concurrency precondition, and workbench readback before retry.
  3. Keep any future submission contract separate and test stale, cross-claim, and cross-tenant approval negatively.
Result

The design can preserve specialist authority, but rec-0.4.2 remains held until its recommendation-write failures are corrected and re-evaluated.

Practice exercise

Threat-model one effect

Choose the highest-consequence effect in your slice and trace it from untrusted content to source-of-truth verification.

  1. Write the typed contract, identity, tenant, scope, policy, approval, and capability requirements.
  2. Define idempotency, timeout, retry, partial failure, and readback behavior.
  3. List secrets and egress paths and minimize model-visible data.
  4. Run denial, injection, replay, cross-tenant, stale-approval, and mismatch tests.
Keep

A tool contract and threat-test matrix that demonstrate service-enforced boundaries.

Review your work

Field rubric

  • No prompt, model output, or tool description grants authority.
  • Identity, tenant, scope, and approval are rechecked at effect time.
  • Retries cannot create unbounded duplicate effects.
  • Readback and recovery cover uncertain outcomes.

Complete when

  • The allowed path works with least privilege.
  • Every named negative test has a visible denial or recovery result.
  • Credentials and restricted data remain outside model context.

Check your understanding

Can an attacker cause the effect by controlling only prompts, retrieved text, or tool output?

Working template

Download the mission artifact, complete it with source evidence, and review it against the rubric above.

Download Tool contract + threat tests template

Guided study and progress

Open this mission in the guided school to confirm the exercise and rubric, save completion in this browser, and resume the ten-mission path.

Open guided mission

Compare and go deeper

This lesson is self-contained. Compare your work with the calibrated answer, then use the attributed references when you need governed detail or additional implementation practice.

Annotated answerFDE Guide reference ↗Attributed technical depth ↗