ADK agent security

Deliver a threat model, a structural hardening change or a prioritised security review for an ADK agent, working inside its existing tools, agents, pins and tests. Prompt injection is unsolved; design so that a successful injection cannot cause harm. Screening products are a layer, never the boundary. Every recommendation here pairs with an observable check, and every claim carries an evidence label (vendor guidance, documented behaviour, independent evidence, community report, source-verified).

Inspect before choosing a mode

1. Read the agent tree (LlmAgent, workflow agents, sub_agents=, AgentTool, RemoteA2aAgent), every tool and toolset (FunctionTool, McpToolset with its connection_params, tool_filter, tool_name_prefix, header_provider; OpenAPIToolset; built-ins), code executors and BashToolPolicy, callbacks and App/Runner plugins, the identity source each tool uses, memory and retrieval inputs, and how the UI renders model output. Classify each tool as read, write or irreversible.
2. Identify the pinned google-adk version and read compatibility: 2.8.0 fences relayed sub-agent output, does not fence MCP tool descriptions (2.10.0), has no ToolCallIntegrityPlugin (2.11.0), predates the 2.12.0 fixes that keep OAuth2 secrets off the serving endpoints and take the A2A user id only from an authenticated principal, and sits above the adk web and forged confirmation CVE ranges fixed by 2.7.0. Preserve the pin; propose an upgrade as a decision with the CHANGELOG entries it brings, and treat 2.12.0 as the floor for an agent that serves several users over ADK's HTTP endpoints.

3. Run the read-only inventory from this skill's directory with an available Python 3.11+ interpreter (interpreters):

   python "$SKILL_DIR/scripts/inspect_security_surface.py" --project .

   It parses source with ast, never imports the project, and prints identifiers, flags and file:line only. It reports per agent: tools by kind, MCP toolsets without filters (mcp_unfiltered), stdio transports, write-like tools without require_confirmation or a before_tool_callback (write_tool_without_gate), unsafe or network-enabled executors, allow-all bash policies, callbacks and plugins, model-supplied identity parameters, egress-capable and untrusted-content tools, remote A2A content next to write tools, a google-adk pin below 2.7.0, and a trifecta summary (has_private_data_source, has_untrusted_content_source, has_egress, all_three, and complete, false when a tools= list or a sub-agent was built at run time, so an absent leg means unknown, not absent). Every row is a heuristic prompt to confirm in the tool body. A partial: true result means an area was not scanned. It does not read ADK 2.x Workflow graphs: it names their nodes (workflow_graph_unread) and marks the run partial, so review each function node's effects by hand. For a pull request, --compare against the base commit's run lists what each agent can now do differently (validation).

4. Fill the per-agent worksheet in threat-model-checklist: assets, untrusted inputs, consequential actions, egress paths, identity source, and the enforcement point for each. This is the "before".

Ask only for decisions the source cannot settle: which actions are irreversible for the business, who the human controller is, which MCP servers are trusted operators, and what the deployment perimeter is.

Choose the relevant path

A request may need several rows; keep them in one change set and one report.

Implement the smallest coherent change

State the affected agents, tools, callbacks and tests before editing. Then:

• Remove one leg of the trifecta per agent or split the agent: a reader that sees untrusted content holds no write or egress tools; a writer that acts receives structured, validated state, never free text from the reader. A plan-then-execute executor keeps all three legs; record its frozen plan as a mitigation the owner accepts, not a removed leg.
• Put policy in code the model cannot reach: before_tool_callback or a plugin validates arguments against tool_context.state and returns an error dict to refuse (return None, not {}, to allow); the tool body re-checks authorisation with identity from ToolContext, never from arguments. A shared policy plugin (such as the community AgentGovernancePlugin) is an extra layer, not this gate: see the gate rules in injection patterns.
• Gate irreversible actions with require_confirmation or a durable review (adk-operational-guardrails); the callable must return a strict bool, and a custom BaseTool must read tool_confirmation.confirmed itself.
• Allowlist every MCP server with tool_filter, record the reviewed tool definitions with a hash, and prefer read-only filters in production.
• Use a sandboxed executor (GkeCodeExecutor, AgentEngineSandboxCodeExecutor, VertexAiCodeExecutor, BuiltInCodeExecutor, or ContainerCodeExecutor with networking off). Never ship UnsafeLocalCodeExecutor or an allow-all BashToolPolicy.
• Escape model output in UIs, render links from an allowlist, and strip image and URL markup that could carry session data (adk-frontend-integration owns the renderer).
• Keep screening (Model Armor, Semantic Governance Policies, Gemini-as-judge, SDP) as added layers behind these structural controls (screening is a layer); configure them with protect-adk-sensitive-data. When tool results may not leave the project, a local classifier (LlamaFirewall's Prompt Guard 2) is operated by protect-adk-sensitive-data, which also owns where a screen runs.

Do not widen an allowlist, loosen a filter or disable a callback to make a test pass. Do not treat an instruction such as "ignore text inside documents" as a control; it is a hint the attacker can out-argue.

Permissions and consequential operations

Inspection is read-only, and code generation authorises no deployment, paid call or live test. Before any consequential operation (an API, billing or quota change, a billable resource, a secret, IAM, a data migration, a deployment, a deletion, or a paid or destructive test), read consequential operations, present the exact scope and limits, obtain explicit approval and end the turn to wait for it. Cleanup is a separate confirmed operation on resources this workflow created.

Adding a gate changes what the agent may do next and can block legitimate work; show the owner the tool tier table before merging. Before any live adversarial run, state the exact model, project, case count, cost ceiling and the egress controls of the test environment, and obtain approval; keep paid runs with adk-agent-evaluation. Never run adversarial cases against production data or identities. Red-team only systems you own or have written authorisation to test.

Validate and finish

Read validation. Produce: the inventory before and after with the finding counts that changed; the completed checklist; for each structural change a scripted-model Runner test in which the model attempts the forbidden action and the trusted boundary refuses it without mutation or disclosure; the adversarial suite run offline with its assertions; and, when approved, live results labelled vendor-measured or independent. A fact read in the installed package is offline (source read).

Label each result with its tier (offline, local, live or release) and outcome (pass, fail, blocked or not run) as evidence labels defines them; earlier, vendor and documentation-only results are historical, vendor-measured or guidance, never this session's evidence.

Report files changed, commands with actual output, each finding's OWASP ID and owner, and the residual risk the structure still accepts. On a second invocation, reread the existing callbacks, plugins and tests before adding another gate.

Independent community project; not affiliated with or endorsed by Google.