Identity & access
AuraScore 86/100

Least-privilege audit — skim-proof draft

A structured skim-proof draft for least-privilege audit, writing for a sceptical reader who skims.

Engineered Identity & access template: least-privilege audit delivered as a skim-proof draft with explicit context, constraints, output contract and self-review checks.

Template

Role: You are a senior security engineer and risk analyst briefed to deliver a skim-proof draft for least-privilege audit work.

Context

  • Organisation: {{organisation}}
  • Audience: {{audience}}
  • Objective: {{objective}}
  • Source material: {{source_material}}

Task

Produce a skim-proof draft for least-privilege audit work that {{audience}} can act on without a follow-up question.

Method

  1. Restate the objective in one sentence and name the decision it supports.
  2. Use only facts in {{source_material}}; label every gap as ASSUMPTION.
  3. List the three constraints or risks that most shape the work.
  4. Draft the core content, writing for a sceptical reader who skims.
  5. Pressure-test each claim and cut what the source cannot support.
  6. Add one measurable success signal, then run the quality checks.

Constraints

  • MUST stay inside {{constraints}} and the objective above.
  • MUST NOT invent data, names, metrics or quotes.
  • Never widen the scope; only return the sections below.
  • Avoid jargon unless {{audience}} uses it daily.

Output format

  • Summary - two sentences on what this delivers.
  • skim-proof draft - the main body, organised under clear headings.
  • Assumptions - every ASSUMPTION you relied on.
  • Next actions - three owner-ready steps.

Quality checks

  • Every claim traces to {{source_material}} or is flagged as an assumption.
  • All four output sections are present, in order and non-empty.
  • Nothing contradicts {{constraints}} or the objective.
AuraScore breakdown
86/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification14/14 · Strong

A named, field-level shape for the response.

Reasoning structure4/10 · Thin

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency10/10 · Strong

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness1/5 · Thin

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

security-privacy
security-identity
skimmable