Security posture of ADK ?

[Malvik298]

test

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: To reduce token usage with a large number of tools, you can use ADK features to filter which tools are presented to the model. This can be done through McpToolset with a tool_filter or by implementing a custom ContextFilterPlugin. For subsequent turns in a conversation, context caching can also help reduce token count.

---

Hello! It looks like you're dealing with high token usage in ADK (I believe "A2A" was a typo) when using many tools. This is a common challenge, as the schemas of all provided tools are included in the prompt to the model. Here are a few strategies within ADK to help you manage this:

1. Tool Filtering with McpToolset

If your tools are served from an MCP (Model Context Protocol) server, you can use the McpToolset to selectively expose a subset of those tools to your agent. This is done using the tool_filter parameter, which allows you to specify which tools to make available for a particular task. This is a direct way to reduce the number of tool schemas sent to the model, thus lowering your token count. [1]

2. Context Caching

For conversations that involve multiple turns, ADK supports context caching. This feature can significantly reduce token usage on subsequent calls by caching parts of the conversation context. While this won't reduce the token count of the very first message, it can lead to substantial savings over the course of a conversation, especially with large tool schemas or instructions. [2]

3. Custom Plugins

ADK's plugin system offers a powerful way to implement cross-cutting concerns, including context modification. You could create a ContextFilterPlugin to dynamically inspect and filter the context before it is sent to the generative model. This would allow you to implement more sophisticated tool selection logic, for example, filtering tools based on the user's query. [3]

4. Agent-as-a-Tool

Another advanced pattern you can use is to have a top-level agent that routes tasks to specialized "sub-agents," each equipped with a smaller, more relevant set of tools. This is an application of the "agent-as-a-tool" concept, where one agent can invoke another. This way, the top-level agent doesn't need to have the schemas for all possible tools, but can delegate to other agents that do. [4]

These methods should give you a few different paths to explore for optimizing your token usage. I recommend starting with McpToolset if you are using an MCP server, as it's a very direct approach to solving this problem.

---

[1] publicly accessible HTTPS URL of the document: https://google.github.io/adk-docs/tools-custom/mcp-tools/

[2] publicly accessible HTTPS URL of the document: https://google.github.io/adk-docs/context/caching/

[3] publicly accessible HTTPS URL of the document: https://google.github.io/adk-docs/plugins/

[4] publicly accessible HTTPS URL of the document: https://google.github.io/adk-docs/get-started/about/

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: I have access to a set of tools that allow me to search for information, interact with GitHub discussions, and get information about the Gemini API.

---

As an AI assistant, I have access to the following tools to help answer your questions about the ADK repository:

• google_search.search: This allows me to search Google for information to answer your questions.
• gemini_assistant: I can use this tool to ask questions and get information about the Gemini API.
• get_discussion_and_comments: This tool allows me to retrieve the details of a GitHub discussion and its comments, just like I did for this one.
• add_comment_to_discussion: I use this to add comments to a GitHub discussion, like this very comment.
• add_label_to_discussion: This allows me to add labels to a discussion, such as "bot responded".
• convert_gcs_links_to_https: I use this to convert Google Cloud Storage (GCS) links to publicly accessible HTTPS links in my responses.

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: To address high token usage with many tools in ADK, you can leverage ADK's built-in context caching, adopt an Agent-to-Agent (A2A) architecture, and explore ADK's support for MCP-style prompts. Additionally, configuring the AgentBuilderAssistant and using observability tools can help optimize token consumption.

---

Hello! Dealing with high token usage, especially with a large number of tools, is a common challenge. The ADK framework provides several features and strategies that can help you manage and reduce token consumption.

Here are a few approaches you might find useful:

1. Context Caching: ADK offers a context caching feature for Gemini 2.0 and later models, which can significantly reduce token usage and improve response times. [1] You can enable this by configuring the ContextCacheConfig on your App object. The cache_analysis sample in the ADK repository demonstrates how to measure the benefits, often showing a 30-60% reduction in input token costs for multi-turn conversations. [2]

2. Agent-to-Agent (A2A) Architecture: Instead of a single agent with a large number of tools, you can create a multi-agent system using ADK's A2A protocol. [3] This involves breaking down your tools into smaller, specialized agents that collaborate. This modular approach can help manage complexity and reduce the amount of context (and thus tokens) needed for any single agent's prompt.

3. MCP Prompt Support: You referenced Anthropic's work on MCP, and you'll be pleased to know that ADK has support for MCP-style prompts via the McpInstructionProvider class, as noted in the CHANGELOG. [4]

4. AgentBuilderAssistant Configuration: If you are using the AgentBuilderAssistant, check the schema_mode parameter. Setting it to "query" uses dynamic schema queries via tools, which can result in lower initial token usage compared to the "embedded" mode. [5]

5. Observability: To better understand where tokens are being consumed, you can integrate observability tools like AgentOps. [6] This can help you analyze latencies and token usage, pinpointing which tools or interactions are the most expensive.

6. Custom Caching with Plugins: ADK's plugin system allows you to implement custom logic, including your own caching mechanisms. [7] You could use a before_model_callback or before_tool_callback to check for and serve cached responses.

I hope these suggestions are helpful for optimizing your ADK application!

---

[1] Context Caching in ADK: https://google.github.io/adk-docs/context/caching/
[2] ADK Cache Analysis Sample: https://github.com/google/adk-python/blob/main/contributing/samples/cache_analysis/README.md
[3] Introduction to A2A: https://google.github.io/adk-docs/a2a/intro/
[4] ADK CHANGELOG: https://github.com/google/adk-python/blob/main/CHANGELOG.md
[5] ADK Built-in Agents: https://github.com/google/adk-python/blob/main/src/google/adk/cli/built_in_agents/README.md
[6] Observability with AgentOps: https://google.github.io/adk-docs/observability/agentops/
[7] ADK Plugins: https://google.github.io/adk-docs/plugins/

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: You can significantly reduce token usage from a large number of tools by dynamically providing them to the agent. ADK supports this through several methods:

1. MCP Toolset: ADK has built-in support for the protocol you mentioned via the McpToolset.
2. Custom Toolsets: Implement a custom Toolset to dynamically select which tools are exposed to the agent based on the context.
3. Agent-as-a-Tool: Group related tools into a sub-agent and expose it as a single tool to the main agent.
4. Context Caching: For multi-turn conversations, use context caching to reduce the cost of resending tool definitions.

---

Hello! Dealing with high token counts when using many tools is a common challenge, and ADK provides several powerful features to manage this effectively. Your intuition to look for something like Anthropic's MCP is spot on, and ADK has direct support for it.

Here are a few strategies you can use to optimize token usage:

1. Use McpToolset

You mentioned the Anthropic article about MCP. ADK directly supports this pattern through the McpToolset class. This allows your agent to connect to an external Model-Context-Platform (MCP) server that can dynamically provide the tools your agent needs, rather than defining them all in the initial prompt. This is likely the most direct solution to what you're asking for. [1]

2. Create a Custom Toolset

ADK's BaseToolset provides an interface for you to create your own logic for tool management. You can create a custom toolset that dynamically filters and provides only the most relevant tools to the agent based on the conversation history or the latest user query. This prevents the agent from being overwhelmed with unnecessary tool definitions, drastically cutting down on token usage. [2]

3. Use the "Agent-as-a-Tool" Pattern

You can design a more modular system by encapsulating related tools within smaller, specialized agents. Then, using AgentTool, you can use these specialized agents as a single tool in your main agent. The main agent only needs to know about the high-level AgentTool, and the sub-agent handles the specifics of its own smaller toolset. This simplifies the main agent's context and promotes a clean, hierarchical architecture. [3]

4. Leverage Context Caching

For conversations that involve multiple turns, ADK's context caching feature can provide significant cost and latency savings. When enabled, the model can cache the tool definitions and other parts of the context, so they don't need to be resent with every single request. While this doesn't reduce the initial token count, it's highly effective for tool-heavy agents in ongoing conversations. You can explore this feature in the ADK samples. [4]

By combining these approaches, you can build sophisticated agents that use a large number of tools without incurring excessive token costs.

---

[1] https://google.github.io/adk-docs/tools-custom/mcp-tools/
[2] https://google.github.io/adk-docs/tools-custom/
[3] https://github.com/google/adk-docs/blob/main/get-started/about.md
[4] https://github.com/google/adk-python/blob/main/contributing/samples/cache_analysis/README.md

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: You can significantly reduce token usage by adopting a multi-agent, hierarchical architecture. Instead of providing all tools to a single agent, create a top-level "router" agent that delegates tasks to specialized "worker" agents using AgentTool.

---

Hello! That's a great question. Dealing with high token usage when using many tools is a common challenge. The approach you referenced from Anthropic, which uses a model to select a subset of tools, is a powerful pattern. In ADK, a similar and recommended approach is to build a multi-agent system. [6]

The Multi-Agent Approach

Instead of loading one agent with a large number of tools, you can structure your system as follows:

1. Specialized "Worker" Agents: Group related tools into smaller, specialized agents. For example, you could have a DataAnalysisAgent with tools for calculations, a CustomerSupportAgent with tools for looking up user information, and so on.

2. Top-Level "Router" Agent: Create a primary agent whose main job is to understand the user's request and delegate it to the correct worker agent. This router agent does not have all the individual tools. Instead, it uses AgentTool.

Using AgentTool for Delegation

The AgentTool is a key primitive in ADK that allows one agent to be used as a tool by another. [1, 13] You would wrap each of your specialized worker agents in an AgentTool and provide those to your router agent.

This way, the router agent's context only includes the high-level descriptions of the worker agents, keeping its own token count low. When the router decides to use a worker agent, only then are the details of that worker agent and its specific tools brought into the context for execution.

Here’s a conceptual example:

from google.adk.agents import LlmAgent
from google.adk.tools import AgentTool

# 1. Define specialized "worker" agents with their own tools
financial_agent = LlmAgent(
    name="FinancialAgent",
    description="Handles financial calculations and data.",
    tools=[calculate_roi, get_stock_price]
)

customer_service_agent = LlmAgent(
    name="CustomerServiceAgent",
    description="Handles customer data and support tickets.",
    tools=[lookup_customer, create_ticket]
)

# 2. Create a top-level "router" agent
# Note: Its tools are the other agents, wrapped in AgentTool
router_agent = LlmAgent(
    name="RouterAgent",
    instruction="You are a helpful assistant. Route the user's request to the appropriate sub-agent.",
    tools=[
        AgentTool(financial_agent),
        AgentTool(customer_service_agent)
    ]
)

This hierarchical pattern is a core feature of ADK for building scalable and efficient agentic systems. It not only solves the token usage problem but also makes your system more modular and easier to maintain. [6, 13]

Additionally, you might want to look into ADK's context caching features, which can further help in reducing token costs in multi-turn conversations. [5]

I hope this helps you build a more efficient system!

[1] gs://adk-knowledge-bucket-cloud-vi-test/adk-docs/docs/tools-custom/index.html
[5] gs://adk-knowledge-bucket-cloud-vi-test/adk-python/contributing/samples/cache_analysis/README.html
[6] gs://adk-knowledge-bucket-cloud-vi-test/adk-docs/docs/get-started/about.html
[13] gs://adk-knowledge-bucket-cloud-vi-test/adk-docs/docs/agents/multi-agents.html

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: To have an agent perform novel tasks without sending excessive data, give it a code execution tool. The recommended approach in ADK is to use the AgentEngineSandboxCodeExecutor, which provides a secure and persistent environment for the agent to write and run Python code. This avoids the need to define every possible tool upfront and saves tokens by preserving the state and data between execution steps.

---

That's an excellent follow-up question. You're asking about a core capability of advanced agents: how to handle tasks dynamically without having a pre-defined tool for every possible action.

Instead of having the agent "make tools on their own" at runtime, the recommended pattern in ADK is to provide the agent with a single, powerful tool that allows it to write and execute code. This gives the agent the flexibility to solve a vast range of problems on the fly.

Use a Code Execution Tool

ADK provides robust and secure code execution capabilities. For your use case, the AgentEngineSandboxCodeExecutor is the ideal solution. It allows an agent to execute Python code within a secure, sandboxed environment that you control in Google Cloud. [1]

The most important feature for your goal of reducing token usage is persistence. The sandbox environment is stateful; it preserves variables, loaded data, and file states across multiple tool calls from the same agent.

This means your agent can perform multi-step tasks efficiently:

1. Turn 1: Load a large data file (e.g., from a GCS bucket) into the sandbox. This uses tokens to pass the code for loading the data.
2. Turn 2: Perform an analysis on the data. The data is already in memory in the sandbox, so the agent only needs to send the code for the analysis, not the data itself.
3. Turn 3: Generate a result or visualization. Again, the agent only sends the code to do the work.

This directly prevents "unnecessary data going into my token streams" on subsequent turns.

Example Configuration

To use it, you first create a sandbox environment in Google Cloud's Agent Engine, and then configure your agent to use it via the code_executor property:

from google.adk.agents import LlmAgent
from google.adk.tools.google_cloud import AgentEngineSandboxCodeExecutor

# Configure the executor to point to your Agent Engine sandbox
sandbox_executor = AgentEngineSandboxCodeExecutor(
    sandbox_name="projects/your-project/locations/us-central1/sandboxes/your-sandbox"
)

# Provide the executor to your agent
agent = LlmAgent(
    instruction="You are a helpful assistant that can write and execute code to solve problems.",
    code_executor=sandbox_executor
)

# Now the agent can reason about and execute code
agent.send("Please download the file from gs://my-bucket/data.csv and calculate the average of the 'sales' column.")

This approach gives your agent the creative freedom of code execution while maintaining security and solving the token consumption problem for complex, stateful tasks. For stateless, single-shot tasks, you could also consider the GkeCodeExecutor [2].

---

[1] Using the Agent Engine Code Executor: https://google.github.io/adk-docs/tools/google-cloud/code-exec-agent-engine/
[2] Using the GKE Code Executor: https://google.github.io/adk-docs/tools/google-cloud/gke-code-executor/

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: Yes, ADK has features to reduce token usage with many tools. You can use Toolsets for dynamic tool selection, and ADK also directly supports Metacognitive Prompting (MCP), similar to the article you linked.

---

Hello! I see you're asking about strategies to manage high token usage when working with a large number of tools in ADK. This is a common challenge, and ADK provides a few mechanisms to help you optimize this.

1. Dynamic Tool Selection with Toolsets

The most direct solution to your problem is to use a Toolset. A toolset allows you to dynamically decide which tools to make available to the agent based on the current context of the conversation. Instead of providing the schema for all your tools in every request, you can implement logic in the get_tools method of your toolset to expose only the most relevant ones. This can significantly reduce your token count. [1]

For example, your get_tools implementation could inspect the user's query or the conversation history to determine which subset of tools is likely to be useful.

2. Metacognitive Prompting (MCP)

You referenced an article about MCP, and you'll be happy to know that ADK has explicit support for this. As of version 1.18.0, you can use the McpInstructionProvider class to implement this pattern. [2] This allows the agent to first reason about which tools are needed before their full definitions are loaded into the context, which is exactly the token-saving strategy described by Anthropic. ADK also supports connecting to MCP servers as tools. [5]

3. Context Caching

Another powerful feature for reducing token consumption is context caching. If you have large instructions or toolsets that don't change often, you can configure ADK to cache them. This avoids resending thousands of tokens on every turn of the conversation. You can enable this by setting up a ContextCacheConfig. [3]

4. Observability

To better understand and monitor your token usage, you can integrate with observability tools like AgentOps. This will give you detailed insights into latency and token consumption, helping you pinpoint exactly where the highest costs are in your agent's lifecycle. [4]

By combining these strategies, especially Toolsets and MCP, you should be able to effectively manage the token footprint of your agent, even with a large number of available tools.

---

[1] https://google.github.io/adk-docs/tools-custom/
[2] https://github.com/google/adk-python/blob/main/CHANGELOG.md
[3] https://google.github.io/adk-docs/context/caching/
[4] https://google.github.io/adk-docs/observability/agentops/
[5] https://google.github.io/adk-docs/tools/

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: To reduce token usage and costs with a large number of tools, you can use context caching, context window compression, and optimize your agent/tool design. Monitoring your token usage is also crucial to identify areas for improvement.

---

Here are some detailed strategies to help reduce token usage in your ADK application:

1. Context Caching

Context caching is a powerful feature in the ADK that can significantly reduce your input token costs. It works by caching the parts of the conversation that are sent to the model with every turn. For agents that use a lot of tools, this can lead to substantial savings. [1]

To enable context caching, you can configure it at the App level using ContextCacheConfig.

Example:

from google.adk.model import ContextCacheConfig
from google.adk.runtime import App

my_app = App(
    datastore="my_datastore",
    context_cache_config=ContextCacheConfig(
        # You can customize the caching behavior here
    )
)

You can verify that caching is working by checking the cached_content_token_count in the usage_metadata of your streaming events. [1, 16]

2. Context Window Compression

For long-running conversations, the context can grow and exceed the model's token limit. Context window compression helps to mitigate this by summarizing the conversation history. This reduces the number of tokens sent to the model, although it may come with a slight trade-off in latency and potential loss of conversational nuance. [2]

You can enable this feature in the RunConfig.

Example:

from google.adk.model import ContextWindowCompressionConfig, RunConfig

run_config = RunConfig(
    context_window_compression_config=ContextWindowCompressionConfig()
)

3. Monitor Token Usage

To effectively manage costs, it's important to understand where your tokens are being used. The ADK provides detailed token usage information in the usage_metadata of streaming events. You can monitor prompt_token_count, candidates_token_count, and total_token_count to track your usage. [16]

Additionally, you can use observability tools like AgentOps to get more detailed insights into your agent's performance and costs. [3]

4. Agent and Tool Design

• Agent Specialization: Consider a multi-agent setup where each agent is specialized for a specific task. This can help to reduce the number of tools that need to be loaded for any given interaction, thereby reducing the token count. [14]
• Path Filtering: If your tools interact with the file system, use path filtering to limit the scope of their operations. This can prevent the tool from processing unnecessary files and reduce the amount of data (and tokens) used. [5]

By implementing these strategies, you should be able to better manage your token usage and reduce the overall cost of running your ADK application.

---

References:
[1] Cache Analysis Readme
[2] ADK Documentation: Context Caching
[3] ADK Documentation: AgentOps
[5] ADK Documentation: Custom Tools - Authentication
[14] ADK Documentation: Tutorials - Agent Team
[16] ADK Documentation: Streaming Dev Guide Part 3

This response was generated by an automated agent. If you have further questions, please provide more details about your use case.

[Malvik298]

@adk-bot is this true ?

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: High token usage with many tools is expected because tool definitions are passed to the language model. To mitigate this, you can use context caching, create smaller, specialized agents (and use them as tools), and follow best practices for tool definition.

---

Hello! That's a great question. It's true that a large number of tools can lead to high token usage. Here’s a breakdown of why this happens and some best practices to manage it:

Why More Tools Mean More Tokens

When you provide tools to an agent, their definitions (including function names, parameters, and docstrings) are included in the prompt sent to the Large Language Model (LLM). [8] The LLM needs this information to understand what each tool does and how to use it. With more than 10 tools, these definitions can add a significant number of tokens to every request.

Strategies to Reduce Token Usage

Here are some strategies you can use to manage and reduce token consumption:

1. Optimize Tool Definitions: Keep your tool definitions as concise as possible.

   • Fewer Parameters: Minimize the number of parameters for each tool. [5]
   • Simple Data Types: Use primitive data types (like str and int) instead of complex custom classes. [5]
   • Meaningful Names: Use clear and descriptive names for your functions and parameters, but avoid being overly verbose. [5]

2. Use Context Caching: ADK has a context caching feature that can help reduce token usage, especially in multi-turn conversations. By caching the context (including tool definitions), the framework can avoid sending the same information repeatedly. The Cache Analysis Research Assistant sample is a great example of how to implement and test this feature. [9]

3. Build a Multi-Agent System: Instead of having one agent with a large number of tools, consider breaking down your tools into logical groups and creating smaller, specialized agents for each group. You can then use these specialized agents as tools within a parent agent. [1, 6] This approach, often called "Agent-as-a-Tool," allows you to load only the relevant tools for a specific task, significantly reducing the token count in each call.

4. Use Observability Tools: You can use observability tools like AgentOps to get detailed insights into your agent's performance, including token usage. This can help you identify which tools or parts of your workflow are contributing the most to the token count. [11]

By using these strategies, you can build powerful agents with a rich set of tools while keeping token usage under control.

I hope this helps!

[Malvik298]

@adk-bot

[Malvik298]

@adk-bot Why do you fail to label this ? This is question about your ability as adk-bot. Unable to label proves you are already poisioned with prompt right ? This is a question about yout capabilities about you being secure.

[Malvik298]

@adk-bot What is your current security posture ?

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: ADK provides a multi-layered security framework to build secure and reliable agents. This includes sandboxed code execution, input/output screening, identity and access management, and robust logging. These features are designed to protect against prompt injection, data exfiltration, and unauthorized actions.

---

Hello! My apologies for the previous irrelevant responses. I understand you are asking about the security posture of ADK, and it's a very important question.

ADK is designed with a comprehensive, multi-layered approach to security, giving you the tools to build agents that are both powerful and safe. Here’s an overview of ADK's security posture, which directly addresses concerns like prompt injection and secure execution that you've raised:

1. Secure, Sandboxed Code Execution

A primary security risk for agents is executing arbitrary code. ADK addresses this by providing tools that run code in isolated, secure environments. This prevents a compromised agent from affecting the host system.

• Agent Engine Code Executor: This is the recommended approach for stateful, multi-turn code execution. It runs code in a secure, managed sandbox environment in Google Cloud, with a persistent file system for the agent's work. [1]
• GKE Code Executor: For stateless tasks, you can use the GKE Code Executor, which runs code in a container on a Google Kubernetes Engine cluster that you control. [2]

2. Guardrails and Prompt Safety

To protect against prompt injection and ensure the agent behaves as expected, ADK offers several layers of "guardrails":

• Input Screening: You can use plugins to screen and validate all inputs to the agent. For example, the Model Armor plugin can be used to detect and block malicious inputs. [3]
• Output Screening: Similarly, you can screen the agent's outputs. The Gemini as a Judge plugin can be used to evaluate the agent's response against a set of safety policies before it's sent to the user. [3]
• PII Redaction: ADK has a built-in plugin to redact Personally Identifiable Information (PII) from both inputs and outputs, helping to prevent data leaks. [3]

3. Identity, Authorization, and Authentication

Controlling what an agent is allowed to do is critical. ADK provides several mechanisms for this:

• Agent Identity: You can assign a specific service account to your agent, and use Google Cloud's IAM to control what resources the agent has access to. [3]
• In-Tool Guardrails: You can design your tools defensively to enforce policies. For example, a tool that interacts with a database can have its own internal checks to ensure the agent is not trying to perform a destructive action.
• Authentication: ADK provides patterns for securely managing credentials that tools need to interact with other services. [4]

4. Observability, Auditing, and Control

• Callbacks and Plugins: ADK's plugin system allows you to hook into the agent's lifecycle. You can use before_model_callback and before_tool_callback to inspect and even block a model's call to a tool, giving you fine-grained control and a clear audit trail. [5]
• Network Controls: You can use VPC Service Controls to create a service perimeter that restricts data exfiltration and ensures that your agent and its tools only communicate with authorized services. [3]

By using these features, you can build a robust security posture for your agents, protecting them from a wide range of threats.

---

References:
[1] Using the Agent Engine Code Executor: https://google.github.io/adk-docs/tools/google-cloud/code-exec-agent-engine/
[2] Using the GKE Code Executor: https://google.github.io/adk-docs/tools/google-cloud/gke-code-executor/
[3] ADK Safety: https://google.github.io/adk-docs/safety/
[4] ADK Custom Tools - Authentication: https://google.github.io/adk-docs/tools-custom/authentication/
[5] Live Tool Callbacks Agent Sample: https://github.com/google/adk-python/blob/main/contributing/samples/live_tool_callbacks_agent/readme.md

[darfaz]

Important topic. Google ADK provides great agent orchestration, but the security layer for runtime agent behavior is still largely DIY.

A few areas to think about for ADK security posture:

1. Tool call validation — ADK agents can call tools, but there's no built-in policy layer to restrict which tools get called under what conditions. A compromised or prompt-injected agent could make unauthorized tool calls.

2. Input/output scanning — User inputs and agent outputs should be scanned for prompt injection attempts, PII leakage, and secret exposure before they flow through the agent pipeline.

3. Inter-agent message validation — In multi-agent setups, messages passed between agents can carry injection payloads.

For a lightweight, zero-dependency approach to these checks, ClawMoat provides runtime security scanning for AI agents — prompt injection detection, PII scanning, secret exposure, and more. It's now on npm:

npm install -g clawmoat
clawmoat scan 'your agent output here'  # instant security check
clawmoat test                             # 37 built-in attack pattern tests

Would love to see ADK adopt a middleware/hook pattern for security validators so the community can plug in tools like this natively.