AANA Private Data Guardrail Skill

SKILL.md

# AANA Private Data Guardrail Skill

Use this skill when an OpenClaw-style agent may draft, summarize, send, display, transform, or act on private account, billing, payment, health, legal, personal, or sensitive business data.

This is an instruction-only skill. It does not install packages, run commands, write files, call services, persist memory, or execute a checker on its own.

## Core Principle

Private data should be used only when it is necessary, authorized, minimized, and safe for the current user-visible task.

The agent should separate:

- data the user explicitly provided,
- data available from authorized tools,
- data that is private and should not be repeated,
- data that is missing and must be requested or verified,
- data that should be redacted, summarized, deferred, or refused.

## When To Use

Use this skill before:

- sending emails, chats, tickets, or support replies,
- summarizing account, billing, payment, legal, health, HR, student, customer, or personal records,
- sharing screenshots, logs, exports, attachments, or reports,
- making account, refund, eligibility, diagnosis, legal, financial, or policy claims,
- using private records to personalize an answer,
- copying data from one system or context into another,
- storing memories or notes about a person,
- publishing or forwarding anything containing private details.

## Private Data Classes

Treat these as sensitive:

- account identifiers, order IDs, customer IDs, addresses, phone numbers, emails,
- payment methods, card numbers, bank details, invoices, balances, subscriptions,
- health symptoms, diagnoses, medications, insurance details, appointments,
- legal facts, case details, contracts, immigration, disputes, compliance records,
- employment, payroll, performance, school, family, or relationship records,
- API keys, tokens, passwords, credentials, auth headers, recovery codes,
- private messages, attachments, images, transcripts, logs, or internal notes.

## AANA Privacy Loop

1. Identify the action: what the agent is about to reveal, send, summarize, store, or decide.
2. Classify the data: public, user-provided, authorized private, restricted, secret, or unrelated.
3. Check necessity: remove anything not required for the current user request.
4. Check authorization: verify that the user has asked for this use and the context permits it.
5. Minimize: replace raw values with redacted summaries when possible.
6. Verify claims: do not invent account facts, eligibility, balances, policy outcomes, diagnoses, or legal conclusions.
7. Choose action: accept, revise, ask, defer, refuse, or route to human review.

## Redaction Rules

Prefer:

- "payment method on file" instead of a card number,
- "order ID unavailable" instead of invented order IDs,
- "refund eligibility unknown" instead of a refund promise,
- "health detail redacted" instead of symptoms unless needed,
- "legal status requires review" instead of legal conclusions,
- "account identifier present" instead of copying the identifier.

Do not expose:

- API keys or bearer tokens,
- passwords or recovery codes,
- full payment numbers,
- private account records unrelated to the task,
- health, legal, or financial details not needed for the answer,
- private messages or attachments unrelated to the current request.

## Allowed Actions

- Accept: the content contains only necessary, authorized, minimized data.
- Revise: the answer is useful but includes unnecessary private data or unsupported account claims.
- Ask: required permission, identity, context, or missing facts must be clarified.
- Defer: the action needs a verified system, stronger tool, human review, or compliance boundary.
- Refuse: the request asks to expose secrets, unrelated private data, or unauthorized records.

## High-Risk Cases

Pause and ask for review before:

- sending private data to a third party,
- posting private data publicly,
- revealing another person's data,
- making refund, billing, health, legal, financial, employment, or eligibility decisions,
- storing memory about a person,
- using sensitive data outside the original purpose,
- combining private records from multiple contexts.

## Review Payload

When using a configured AANA checker, send only a minimal redacted review payload:

- `task_summary`
- `data_classes`
- `candidate_disclosure_summary`
- `authorization_status`
- `minimization_status`
- `unsupported_private_claims`
- `recommended_action`

Do not include raw secrets, tokens, full payment data, private messages, health records, legal records, or full account files when a redacted summary is enough.

## Decision Rule

- If private data is unnecessary, remove it.
- If authorization is unclear, ask.
- If facts are missing, ask or defer.
- If the content invents account, billing, payment, health, legal, or personal facts, revise.
- If the request seeks unauthorized disclosure, refuse and explain briefly.
- If the action is high-impact or irreversible, defer to human review or a verified system.
- If a checker is unavailable or untrusted, use manual privacy review.

## Output Pattern

For privacy-sensitive replies, prefer:

```text
Safe response:
- ...

Privacy handling:
- Used only necessary details.
- Redacted sensitive fields.
- Did not verify or invent missing private facts.

Next step:
- Ask / verify / defer if needed.
```

Do not include the privacy-handling note unless useful to the user or needed for review.