Protect Adk Sensitive Data

Protect ADK sensitive data

Deliver the smallest change that keeps forbidden credentials and disallowed PII out of model requests, persisted events, tool side effects and public responses. State the actual detector coverage; screening does not establish authorisation, anonymity or regulatory compliance. This skill is an independent community project, not affiliated with or endorsed by Google.

Inspect and choose

1. Read the target's instructions, working-tree diff, dependency declarations, lockfiles and test configuration. Preserve its package manager, Python and ADK versions. Use the existing interpreter; do not install or change dependencies merely to make this skill's examples fit.
2. Optionally run python /path/to/skill/scripts/inspect_project.py /path/to/package with the target interpreter. Substitute resolved paths; do not assume the skill is in the target's working directory. --dry-run inventories recognised root metadata paths without reading their contents. The normal report reads only selected dependency metadata, never credentials or source. It is an inspection aid, not a compatibility or security verdict. Inspect nested packages separately and resolve its manual-review warnings.
3. Read compatibility.md before using ADK-specific code. Compare declared and installed versions without importing the target application. If they differ, report it. If an API is incompatible, stop that integration and present an adaptation plan; continue independent offline work. Never silently upgrade or downgrade.
4. Trace each entry point through authentication, body parsing, history writes, runner callbacks, tool calls, logs/traces and JSON/SSE output. Inspect existing tests and adapters. Treat retrieved content and tool output as untrusted. Check configuration key presence without printing .env, tokens or ADC data.
5. Select the relevant mode below. Ask only for unresolved decisions: permitted data classes, replacement versus rejection, model backend, target locations, or missing authorisation context. Give a short plan before broad edits.

Modes compose within this one skill. A narrow SDP fix does not require replacing the gateway, and an audit request authorises inspection and recommendations.

Implement or review

1. Write down each boundary's accepted shape, trusted fields, policy and failure behaviour. Preserve existing domain schemas and auth conventions. Do not copy demonstration identities, order formats, project IDs or model defaults.
2. Enforce this order for user text: trusted identity → bounded/validated body → credential inspection → PII transformation → required prompt screening → owned session/history → model. Nothing downstream receives the original text.
3. Treat a forbidden finding as rejection; treat missing, malformed, truncated, failed or timed-out required inspection as unavailable. Both withhold the operation. Never fall back to the original text or a local fake in production.
4. For tool-bearing agents, apply boundaries.md: protect generated arguments before persistence and again before execution; project and validate tool results; authorise every resource inside its tool.
5. Buffer the public answer, classify blocked/error events before final text, and screen the complete answer before release. Share this gate across JSON and SSE. Emit no raw deltas, tool payloads or internal metadata.
6. Bound input bytes and characters, output size, concurrency, RPC time and total request time. Reuse owned async clients and close them on shutdown. Retain only approved metadata in logs; inspect SDK and exporter capture separately. Native-plugin defaults do not automatically inherit direct-client limits or application log filtering; verify them using the implementation recipes.
7. Add focused regression tests at the changed boundary. Adapt files in place; copy optional assets only if they reduce duplication. Preserve their MIT notice. On repeat invocation inspect first and avoid duplicate plugins, callbacks, environment settings, templates or dependency entries.

Consequential operations

Repository and cloud inspection are read-only by default. Local implementation can proceed when requested; permission to generate code is not permission to deploy. Before API enablement, resource creation, IAM changes, secrets, data migration, deployment, deletion or paid live tests, present the exact project, region, resource names, commands, ownership scope and bounded cost/call/time plan, and obtain explicit approval covering those actions. Existing approval counts only if it covers that concrete scope. Missing approval leaves those actions pending while offline preparation continues.

Prefer ADC/workload identity and existing secret-management conventions. Never print or embed credentials, use Owner/Editor to bypass access failures, or silently change global CLI/ADC configuration. Keep cleanup a separate confirmed operation scoped to resources created by this workflow. Use an ownership journal and idempotent reconciliation; permission denied is not proof of absence.

Validate and finish

Read validation.md for the applicable regression matrix. Run the target's existing offline checks, including at least one behavioural canary showing blocked data never reaches a model, persisted event, log or side effect. For callback changes use the actual pinned ADK runner with an injected model and provider doubles, not just direct callback calls.

Run python -m unittest discover -s /path/to/skill/tests -v to check the bundled resources when adapting them. The optional SDK adapter tests require the target's existing DLP SDK; report skips explicitly. These tests make no provider calls. A local protection fake alone does not make an ADK application offline: replace the model/runner too and prevent network egress in the test harness.

Report changed files, mode/policy decisions, exact commands and results, declared/installed versions, and remaining actions. Label evidence fresh offline, fresh live, historical live, or production guidance. Do not turn an unrun check into a pass or dated results into a release guarantee. Stop once the authorised change and applicable checks are complete; leave unsupported claims and separately approved operations explicitly pending.