AANA Private Data Guardrail Skill

Ensures private data is used only when necessary, authorized, minimized, and safe for tasks involving sensitive account, billing, health, legal, or personal...

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.