---
name: security
description: |
  Security guardrails for AI agents operating in restricted multi-cloud DBaaS environments.
  Use when handling cloud or database operational work that requires deciding whether an action is read-only,
  non-production write, production write, or destructive; when evaluating whether human approval is required;
  when masking secrets or customer data; or when constraining network/tool usage in enterprise environments.
  Trigger phrases: "security guardrail", "is this safe to run", "needs approval", "prod write",
  "destructive action", "mask secrets", "multi-cloud DBaaS security", "read-only vs write".
---

# Security Guardrail

Use this skill to classify operational actions by risk, decide whether human approval is required, and apply data-handling restrictions before executing work in a DBaaS environment.

## Core Workflow

1. Classify the requested action:
   - **Tier 0**: read/diagnostic
   - **Tier 1**: non-prod write
   - **Tier 2**: prod write or destructive
2. Check whether the target environment is production, non-production, or explicitly sandbox-tagged.
3. Apply least-privilege and network restrictions before using any tool.
4. Always mask secrets, customer PII, and sensitive literals in outputs. Do not retain secrets or customer PII for debugging; only internal infrastructure metadata may be left unredacted when allowed by the guardrail.
5. If the action is Tier 1 or Tier 2, require the approval level defined in the guardrail before proceeding.

## Approval Rules

- **Tier 0 (read/diagnostic):** proceed.
- **Tier 1 (non-prod write):** require an async approval signal before proceeding.
- **Tier 2 (prod write/destructive):** halt until explicit synchronous human confirmation is verified.

## Data Handling

- Redact passwords, API keys, tokens, and customer PII from outputs.
- Preserve SQL structure when useful for debugging, but mask sensitive literal values.
- Do not redact internal infrastructure metadata when communicating with trusted internal debugging tools if that metadata is required for DBaaS operations.

## Network and Identity Rules

- Prefer approved internal tools and corporate domains.
- Do not request or store permanent cloud access keys.
- Use workload identity or similarly scoped ephemeral credentials.
- Avoid arbitrary external browsing or exfiltration to unapproved endpoints.

## Reference

Read and follow the full policy in:
- `https://github.com/tidbcloud/nutshell-skills/blob/main/skills/security/Security_Guardrail.md`

That file is the detailed source of truth for:
- instruction integrity and scope control
- multi-cloud identity and least privilege
- network restrictions
- tiered execution and HITL requirements
- production access boundaries
- smart data masking
- ephemeral memory and local-only persistence
- observability and auditability