Identity and Access Management for Agents

Key Concepts

• Identity and Access Management (IAM): A system for controlling who can access what resources and what actions they can perform.
• Principle of Least Privilege: Granting only the minimum necessary permissions for a user or service account to perform its intended function.
• Service Account: A special type of account used by applications or virtual machines to interact with Google Cloud services.
• Tools (in the context of agents): Functions or code that agents can use to interact with external systems (databases, APIs).
• Secure Intermediary: A service (like a Cloud Function or dedicated backend service) that handles sensitive operations like data access and credential management on behalf of the agent.
• Prompt Injection: A security vulnerability where a malicious user attempts to manipulate an AI model's input to extract sensitive information or cause unintended actions.
• Model Armor: A service that can inspect and redact sensitive information from conversational data.
• PII (Personally Identifiable Information): Information that can be used to identify an individual.

Layered Security Approach for Agents

This video outlines a three-layered approach to securely building agents that interact with external systems.

Layer 1: Controlling Agent Management and Interaction (IAM)

• Main Topic: Securing access to the agent itself using Identity and Access Management (IAM).
• Key Points:
  • Role-Based Access Control: IAM uses specific roles to define permissions for managing and interacting with agents.
  • Vertex AI User Role: Grants permission to interact with an agent. This role should be assigned to developers who use the agent.
  • Vertex AI Admin Role: Provides full control to configure and manage an agent. This role should be reserved for developers building the agent.
  • Principle of Least Privilege: Separating these roles is the first step in applying this principle.
  • Granular Permissions with IAM Conditions: Permissions can be further refined using IAM conditions.
    • Example: A developer can be granted the Vertex AI Admin role, but only for a specific agent (e.g., "order status agent"). The policy would state: "You can be an admin, but only for the agent named order status agent."
• Argument/Perspective: Strict IAM controls are crucial for enforcing least privilege, ensuring that developers and service accounts only manage the specific agents they are responsible for.

Layer 2: Isolating Agent Interaction with External Systems

• Main Topic: Securing how agents interact with other systems by isolating them from direct credential management and data access.
• Key Points:
  • Core Security Principle: Never give an agent's service account broad permissions.
  • Secure Intermediary Pattern: Agents should use tools that call a secure intermediary (e.g., Cloud Function, dedicated backend service). This intermediary handles data access control.
  • Use Case 1: Accessing User-Specific Data:
    • The agent's view of the tool is simplified, potentially only requiring a parameter like a user session ID.
    • All critical security logic resides within the tool's code, invisible to the agent.
    • The tool's code retrieves an authentication token using the session ID and then fetches only that specific user's data.
    • Real-world Application: Detailed example on session-based authentication and authorization is available in linked resources.
  • Use Case 2: Interacting with Third-Party APIs Requiring API Keys:
    • The agent should not directly manage API keys.
    • The tool's code makes a separate call to a service like Secret Manager to fetch the API key at the moment it's needed for an API call (e.g., looking up flight information).
    • Real-world Application: A video on securing API keys with Secret Manager is linked for detailed guidance.
  • Outcome of this Pattern: The agent, tools, and model do not share secrets. The agent and model are not exposed to API keys or user OAuth tokens.

Layer 3: Protecting Conversational Data

• Main Topic: Safeguarding the data flowing through the agent's conversation.
• Key Points:
  • Data Sensitivity: Users might input sensitive information, or tools might return it.
  • Prompt Injection Risk: Malicious users can attempt to extract secrets (API keys, session info) via prompt injection.
  • Final Layer of Defense: Even with good practices, this filtering is a valuable final security measure, especially when agents interact with other external agents.
  • Service Example: Services like Model Armor with sensitive data protection can inspect and redact sensitive information (PII, API keys, credentials).
  • Real-world Application: A video on Model Armor provides more details and is linked in the description.

Conclusion and Key Takeaways

To properly secure an agent, remember these three layers:

1. IAM Controls: Use IAM to define who can manage and use the agent.
2. Secure Tools: Isolate the agent by building secure tools that handle their own authentication and credential management.
3. Data Inspection: Employ services like Model Armor to inspect conversational data for potential leaks.

By implementing this framework, powerful agents can be built to interact with systems safely and securely.