{
  "date": "2026-10-07",
  "generated_at": "2026-10-07T19:28:39.961487+08:00",
  "hours": 24,
  "items": [
    {
      "title": "Announcing MCP Toolbox Java SDK v1.0: Agentic data access for the enterprise",
      "url": "https://cloud.google.com/blog/topics/developers-practitioners/announcing-mcp-toolbox-java-sdk-v10-agentic-data-access-for-the-enterprise",
      "source": "Google Cloud · Agent 身份",
      "published": "2026-10-07T03:00:00+08:00",
      "excerpt": "Co-authors: Stenal Jolly , Strategic Cloud Engineer, Google Anubhav Dhawan , Software Engineer, Google Following the landmark announcement of MCP Toolbox v1.0, we're thrilled to announce that the MCP Toolbox Java SDK has officially reached version 1.0. This release brings first-class, type-safe agent orchestration to one of the world's most widely adopted enterprise ecosystems. Java's mature architecture is purpose-built for rigorous demands, providing the high concurrency, strict transactional integrity, and robust state management required to safely scale mission-critical AI agents in production. In this post, we'll tell you about what's ne",
      "topics": [
        "ai_agent"
      ],
      "is_new": false,
      "first_seen": "2026-10-07T17:38:33.161622+08:00",
      "article": {
        "ok": true,
        "final_url": "https://cloud.google.com/blog/topics/developers-practitioners/announcing-mcp-toolbox-java-sdk-v10-agentic-data-access-for-the-enterprise",
        "text": "Developers & Practitioners\nAnnouncing MCP Toolbox Java SDK v1.0: Agentic data access for the enterprise\nOctober 7, 2026\nAbirami Sukumaran\nStaff Developer Advocate, Google\nCo-authors:\nStenal Jolly\n, Strategic Cloud Engineer, Google\nAnubhav Dhawan\n, Software Engineer, Google\nFollowing the\nlandmark announcement\nof MCP Toolbox v1.0, we're thrilled to announce that the\nMCP Toolbox Java SDK\nhas officially reached version 1.0.\nThis release brings first-class, type-safe agent orchestration to one of the world's most widely adopted enterprise ecosystems. Java's mature architecture is purpose-built for rigorous demands, providing the high concurrency, strict transactional integrity, and robust state management required to safely scale mission-critical AI agents in production.\nIn this post, we'll tell you about what's new in Java SDK v1.0, show you a real-world example, and help you get started with your own implementation.\nMCP: The universal interface\nToday, developers face a compounding integration bottleneck: if you have\nN\ndifferent AI models and\nM\nenterprise data sources, you must build, secure, and maintain\nN × M\nbespoke, custom connections. This lack of a unified integration layer forces engineering teams to rely on a fragmented web of ad-hoc pipelines. As a result, scaling an agentic architecture quickly becomes unsustainable, exposing sensitive enterprise databases to severe security vulnerabilities, fragmented access controls, and massive maintenance overhead.\nEliminating the fragmented web of custom integrations is the core problem solved by the Model Context Protocol (MCP). Acting as a universal interface—the \"USB Type-C\" for AI orchestration—MCP decouples models from data sources. Instead of writing custom or managed API integration code for every new model or database, developers write to a single, standardized protocol. This approach allows any MCP-compliant agent to securely and immediately interact with any MCP-enabled system. The MCP connection lets developers connect agents to real-world systems without building bespoke integrations for every new model.\nWhat's new in Java SDK v1.0: Built for production workloads\nWhen we announced the\npublic Beta\nfor the MCP Toolbox Java SDK, our goal was to bring first-class, type-safe agent orchestration to enterprise Java environments. Since then, we've collaborated with developers and open-source contributors to harden our APIs.\nThe v1.0 release marks a stable, backwards-compatible foundation suitable for enterprise workloads. Here's what's new and hardened since our v0.2 release:\nTransport layer abstraction &\nHttpMcpTransport\n: We introduced a clean transport layer abstraction alongside\nHttpMcpTransport\n. This feature decouples the core protocol logic from underlying HTTP clients, making it easy to swap network implementations or customize connection pooling.\nDecoupled client authentication\n: To simplify enterprise security compliance, client authentication is now decoupled using\nCredentialsProvider\nand\nAuthMethods\nclasses\n. Credentials are resolved asynchronously on every request, so teams can refresh tokens dynamically or plug in their own token source (Google OIDC via ADC ships in the box, anything else is a one-method interface).\nDefault parameter support\n: Native support for default values in tool parameters, reducing prompt payload sizes and enhancing agent reliability.\nPruning bound parameters\n: Sensitive parameters that are bound server-side (like\ntenant_id\n) are now automatically stripped from exposed tool definitions so the LLM can't manipulate them.\nVersion selection & session tracking\n: Standardized MCP version selection and robust session tracking ensure consistent protocol negotiation and conversation-state lifecycles.\nHTTP credential exposure warnings\n: Added built-in detection that warns you at runtime when credentials are about to travel over a plaintext HTTP connection.\nGeneric client headers map\n: Easily attach custom corporate proxy headers, transaction tracing IDs, or correlation metadata to all outgoing requests.\nGet started with the Java SDK v1.0\nWe designed the MCP Toolbox Java SDK to be frictionless for enterprise teams. Just add the following dependency to your\npom.xml\n:\nLoading...\n<dependency>\r\n    <groupId>com.google.cloud.mcp</groupId>\r\n    <artifactId>mcp-toolbox-sdk-java</artifactId>\r\n    <version>1.0.0</version>\r\n</dependency>\nReal-world example: The autonomous transit concierge\nTo demonstrate the power of the Java SDK combined with AlloyDB, let's look at an enterprise use case.\nMeet\nCymbal Transit\n, a fictitious intercity bus network. Customers don't want to click through nested dropdown menus to plan a trip. They want to ask:\n\"I need to get from New York to Boston tomorrow morning. Can I bring my Golden Retriever? If so, book me the fastest trip.\"\nTo answer this question, an AI agent must cross-reference unstructured data (pet policies) with structured data (schedules and seat availability) and execute a transaction (booking)—all while maintaining the context of the conversation.\nThe foundation: AlloyDB schema with native embeddings\nWe used AlloyDB for this implementation because it handles relational data and high-dimensional vectors natively. Set up your database tables with these statements:\nlang-sql\nLoading...\n-- Enable necessary extensions for semantic search and embeddings\r\nCREATE EXTENSION IF NOT EXISTS vector;\r\nCREATE EXTENSION IF NOT EXISTS google_ml_integration;\r\n\r\n-- Table 1: Transit Policies (Unstructured Data for RAG)\r\nCREATE TABLE transit_policies (\r\n    policy_id SERIAL PRIMARY KEY,\r\n    category VARCHAR(50),\r\n    policy_text TEXT,\r\n    policy_embedding vector(768)\r\n);\r\n\r\n-- Table 2: Intercity Bus Schedules (Structured Data)\r\nCREATE TABLE bus_schedules (\r\n    trip_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n    origin_city VARCHAR(100),\r\n    destination_city VARCHAR(100),\r\n    departure_time TIMESTAMP,\r\n    arrival_time TIMESTAMP,\r\n    available_seats INT DEFAULT 50,\r\n    ticket_price DECIMAL(6,2)\r\n);\r\n\r\n-- Table 3: Booking Ledger (Transactional Action Data)\r\nCREATE TABLE bookings (\r\n    booking_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n    trip_id UUID REFERENCES bus_schedules(trip_id),\r\n    passenger_id VARCHAR(100),\r\n    status VARCHAR(20) DEFAULT 'CONFIRMED',\r\n    booking_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP\r\n);\nMapping intents to SQL: The\ntools.yaml\nThe MCP Toolbox lets you define custom tools securely. Rather than granting the LLM direct database access, a\ntools.yaml\nconfiguration maps natural language intents directly to parameterized, safe queries:\nLoading...\nkind: source\r\nname: alloydb\r\ntype: alloydb-postgres\r\nproject: my-project\r\nregion: us-central1\r\ncluster: my-cluster\r\ninstance: my-instance\r\ndatabase: postgres\r\n---\r\nkind: tool\r\nname: query-schedules\r\ntype: postgres-sql\r\nsource: alloydb\r\ndescription: Find available bus schedules between cities.\r\nparameters:\r\n  - name: origin\r\n    type: string\r\n    description: The departure city name.\r\n  - name: destination\r\n    type: string\r\n    description: The arrival city name.\r\n  - name: limit\r\n    type: integer\r\n    description: Maximum number of schedules to return.\r\n    default: 5\r\nstatement: |\r\n  SELECT CAST(trip_id AS TEXT) AS trip_id, departure_time, ticket_price\r\n  FROM bus_schedules\r\n  WHERE lower(origin_city) = lower($1) AND lower(destination_city) = lower($2)\r\n  ORDER BY departure_time ASC\r\n  LIMIT $3\nFor the complete YAML file, see the\ntools.yaml\nfile in the\nmcp-toolbox-sdk-java\nrepository.\nStateful agent architecture in Spring Boot\nThe hardest part of building conversational AI in enterprise applications is managing state: when a user asks, \"What times are available?\" and follows up with, \"Book the 8 AM one,\" the agent must remember prior context across turns.\nUsing the Java MCP Toolbox SDK with Spring Boot and LangChain4j, we can cleanly maintain conversational memory in the HTTP Session and we can cleanly separate the agent into two declarative components:\nA declarative agent interface that manages the prompt, tools, and conversational memory via an HTTP session.\nA tool execution service that routes agent requests directly to the MCP Toolbox server.\nLoading...\ninterface TransitAgent {\r\n    @SystemMessage({\r\n        \"You are the Cymbal Transit Concierge.\",\r\n        \"Use the 'querySchedules' tool for finding schedules.\",\r\n        \"Use 'bookTicket' to execute transactions.\",\r\n        \"Use 'searchPolicies' to look up luggage and pet rules.\"\r\n    })\r\n    String chat(@MemoryId String sessionId, @UserMessage String userMessage);\r\n}\r\n\r\n@Service\r\nclass TransitAgentTools {\r\n    // These methods automatically invoke our MCP Toolbox server!\r\n    @Tool(\"Query specific schedules between an origin and destination city.\")\r\n    public String querySchedules(String origin, String destination) { ... }\r\n\r\n    @Tool(\"Book a ticket for a passenger.\")\r\n    public String bookTicket(String tripId, String passengerName) { ... }\r\n\r\n    @Tool(\"Search transit policies for luggage and pet rules.\")\r\n    public String searchPolicies(String query) { ... }\r\n}\nNotice how the\n@MemoryId\nannotation abstracts session tracking: Spring Boot automatically correlates conversational context to the user's HTTP session. Meanwhile, LangChain4j and the MCP Toolbox handle schema translation and tool routing behind the scenes—no handwritten if/else intent parsing required.\nBy pairing the MCP Toolbox Java SDK with LangChain4j, we achieve clean separation of concerns and effortless state management:\nZero-boilerplate session management\n: The\n@MemoryId String sessionId\nparameter binds conversation history directly to the user's HTTP session.\nDeclarative agent contract\n: The\nTransitAgent\ninterface defines the model's persona and system instructions without complex prompt templating.\nType-safe tool execution\n: The\nTransitAgentTools\nSpring service wraps remote MCP database tools as native Java methods.\nThis architecture ensures your agent remains modular: you can refine prompt guidance in the interface, manage user sessions automatically, and execute secure database queries through MCP Toolbox without tight coupling.\nConnecting the dots: Listing, invoking, and executing tools in Java v1.0\nNow let's look under the hood of the\nTransitAgentTools\ninterface. Inside those LangChain4j\n@Tool\nmethods on our Spring\n@Service\n, the MCP Toolbox Java SDK handles the heavy lifting—bridging your Java service methods to the MCP tools defined in the\ntools.yaml\nfile. In just a few lines of type-safe code, we can initialize our client using the new v1.0 decoupled authentication and headers abstractions:\nLoading...\n// 1. Initialize the Client with Decoupled Auth and Custom Headers (v1.0)\r\nString serviceUrl = \"https://toolbox-my-project-uc.a.run.app/mcp\";\r\nMcpToolboxClient mcpClient = McpToolboxClient.builder()\r\n    .baseUrl(serviceUrl)\r\n    .credentialsProvider(new GoogleCredentialsProvider(serviceUrl)) // Decoupled OIDC credentials\r\n    .headers(Map.of( // Generic client headers\r\n        \"X-Correlation-ID\", \"enterprise-session-abc123\",\r\n        \"X-Client-Platform\", \"Spring-Boot\"\r\n    ))\r\n    .build();\r\n\r\n// 2. Listing Discoverable Tools\r\nmcpClient.listTools().thenAccept(tools -> {\r\n    System.out.println(\"Successfully discovered \" + tools.size() + \" tools.\");\r\n});\r\n\r\n// 3. Invoking a Tool (Read-Only Data with Default Parameter Support)\r\n// \"limit\" is omitted: the SDK fills it from the default in the tool definition\r\nString schedules = mcpClient.loadTool(\"query-schedules\")\r\n    .thenCompose(tool -> tool.execute(Map.of(\r\n        \"origin\", \"New York\",\r\n        \"destination\", \"Boston\")))\r\n    .join().text();\r\n\r\n// 4. Executing a Transactional Tool (Using Bound Parameters)\r\nAuthTokenGetter toolAuthGetter = () -> CompletableFuture.completedFuture(myIdToken);\r\n\r\nString bookingConfirmation = mcpClient.loadTool(\"book-ticket\", Map.of(\"google_auth\", toolAuthGetter))\r\n    // Bind the authenticated user context securely. bindParam returns a new immutable\r\n    // Tool, and the bound parameter is pruned from the definition exposed to the LLM!\r\n    .thenCompose(tool -> tool.bindParam(\"passenger_name\", \"Jane Doe\")\r\n        // Execute the mutable transaction\r\n        .execute(Map.of(\"trip_id\", \"123e4567-e89b-12d3-a456-426614174000\")))\r\n    .join().text();\nSecure by default: authentication and deployment\nMoving an AI agent to production requires rock-solid credential handling and an infrastructure that scales with demand. Let's look at how you can enforce credential safety across environments and deploy independently on Cloud Run.\nApplication Default Credentials (ADC) & safety\nBy using the\nGoogleCredentialsProvider\nservice\n, your Java app inherits its secure identity from its execution environment (whether local or in Google Cloud) through Application Default Credentials (ADC)—no hard-coded keys, with OIDC tokens minted and cached per audience under the hood. Furthermore, v1.0 offers HTTP Credential Exposure Warnings that automatically detect when credentials are about to travel over a plaintext HTTP connection and emit a runtime warning telling you to switch to HTTPS.\nDeploying the fleet to Cloud Run\nBecause MCP Toolbox and the Spring Boot Agent are fully decoupled, they scale independently on Google Cloud Run to meet high concurrency and stateful conversation requirements.\nTo set up and configure Toolbox on Cloud Run, download the open-source MCP Toolbox for Databases and then follow the\ndeployment guide\n.\nGet started today\nWith MCP Toolbox Java SDK v1.0, enterprise Java teams can wire Spring Boot and LangChain4j agents to the Toolbox server, and through it, to AlloyDB and every other supported data source. When you use the toolbox, arguments are validated against the tool definition before they leave the JVM, authentication is decoupled, and custom headers are attached to every outgoing request. The following\nimplementation steps will help you get started\n.\nStep 1: Add the Dependency\nTo start building with the SDK, add the following dependency to your Maven project's\npom.xml\nfile:\nLoading...\n<dependency>\r\n        <groupId>com.google.cloud.mcp</groupId>\r\n        <artifactId>mcp-toolbox-sdk-java</artifactId>\r\n        <version>1.0.0</version>\r\n <!-- {x-version-update:mcp-toolbox-sdk-java:current} -->\r\n    </dependency>\nStep 2: Explore Resources & Demos\nGitHub Repository\n:\nJava SDK for interacting with the MCP Toolbox for Databases\nOfficial Documentation\n:\nMCP Toolbox for Databases\nDemo Application\n: To experience the Java SDK V1.0 for MCP Toolbox latest, try the sample application\nCymbal transit project\n.\nGradle implementation\nIf your team uses Gradle instead of Maven, remember they will need to translate this dependency:\nLoading...\nimplementation 'com.google.cloud.mcp:mcp-toolbox-sdk-java:1.0.0'\nAutomatic version tracking\nI\nf you copy this setup into automated internal repositories, k\neep the XML comment\n<!-- {x-version-update...} -->\nintact. It's required by the release manager's deployment scripts to automatically bump versions.\nNow that you can integrate your modern agentic tools and servers to your enterprise Java applications with a stale MCP Toolbox Java SDK, get started today!\nPosted in\nDevelopers & Practitioners\nRelated articles\nDevelopers & Practitioners\nNetworking for AI inference model serving - GKE only and for all other backends\nBy Ammett Williams • 6-minute read\nContainers & Kubernetes\nGKE CPU startup boost: Accelerate app starts without over-provisioning\nBy Abdel Sghiouar • 6-minute read\nDevelopers & Practitioners\nDemocratizing Managed Lustre with lower cost and frictionless development\nBy Barak Epstein  • 6-minute read\nDevelopers & Practitioners\nIntroducing the Server Side Cloud Swift SDK\nBy Karl Weinmeister • 6-minute read",
        "metadata": {
          "referrer": "origin",
          "viewport": "initial-scale=1, width=device-width",
          "track-metadata-page_hosting_platform": "blog_boq",
          "mobile-web-app-capable": "yes",
          "apple-mobile-web-app-capable": "yes",
          "application-name": "Google Cloud Blog",
          "apple-mobile-web-app-title": "Google Cloud Blog",
          "apple-mobile-web-app-status-bar-style": "black",
          "msapplication-tap-highlight": "no",
          "description": "Discover MCP Toolbox Java SDK v1.0: secure, type-safe agent orchestration for enterprise Java, with decoupled auth and AlloyDB & Spring Boot support.",
          "robots": "max-image-preview:large",
          "og:title": "Announcing MCP Toolbox Java SDK v1.0: Agentic data access for the enterprise | Google Cloud Blog",
          "og:type": "website",
          "og:url": "https://cloud.google.com/blog/topics/developers-practitioners/announcing-mcp-toolbox-java-sdk-v10-agentic-data-access-for-the-enterprise",
          "og:image": "https://storage.googleapis.com/gweb-cloudblog-publish/images/announcing-mcp-toolbox-java-sdk-v10-agenti.max-1300x1300.png",
          "og:description": "Discover MCP Toolbox Java SDK v1.0: secure, type-safe agent orchestration for enterprise Java, with decoupled auth and AlloyDB & Spring Boot support.",
          "og:site_name": "Google Cloud Blog",
          "twitter:card": "summary_large_image",
          "twitter:url": "https://cloud.google.com/blog/topics/developers-practitioners/announcing-mcp-toolbox-java-sdk-v10-agentic-data-access-for-the-enterprise",
          "twitter:title": "Announcing MCP Toolbox Java SDK v1.0: Agentic data access for the enterprise | Google Cloud Blog",
          "twitter:description": "Discover MCP Toolbox Java SDK v1.0: secure, type-safe agent orchestration for enterprise Java, with decoupled auth and AlloyDB & Spring Boot support.",
          "twitter:image": "https://storage.googleapis.com/gweb-cloudblog-publish/images/announcing-mcp-toolbox-java-sdk-v10-agenti.max-1300x1300.png",
          "twitter:site": "@googlecloud",
          "track-metadata-page_post_title": "Announcing MCP Toolbox Java SDK v1.0: Agentic data access for the enterprise",
          "track-metadata-page_post_labels": "Developers & Practitioners",
          "track-metadata-page_first_published": "2026-10-07 09:10:00",
          "published_time": "2026-10-07T09:40:46+0800",
          "track-metadata-page_last_published": "2026-10-07 10:10:00",
          "track-metadata-page_post_author": "Abirami Sukumaran",
          "track-metadata-page_post_author_role": "Staff Developer Advocate, Google",
          "authors": "Abirami Sukumaran",
          "page": "59670",
          "locale": "en",
          "content_type": "blog.articlepage",
          "tags": "Developers & Practitioners",
          "read_duration": "8"
        },
        "extraction": "article/main",
        "verified": false
      }
    },
    {
      "title": "Improving SPIRE security and resiliency with AWS managed services",
      "url": "https://aws.amazon.com/blogs/security/improving-spire-security-and-resiliency-with-aws-managed-services",
      "source": "AWS Security",
      "published": "2026-10-07T02:52:25+08:00",
      "excerpt": "In cloud-centered environments, establishing trust between workloads is fundamental to securing machine-to-machine communication. Traditional approaches such as API keys, shared secrets, and static service account credentials weren’t designed for the scale and ephemeral nature of cloud workloads. This drives an organizational need to shift from long-term, static credentials to short-lived cryptographic workload identities. Organizations are […]",
      "topics": [
        "identity"
      ],
      "is_new": false,
      "first_seen": "2026-10-07T17:38:33.161622+08:00",
      "article": {
        "ok": true,
        "final_url": "https://aws.amazon.com/blogs/security/improving-spire-security-and-resiliency-with-aws-managed-services/",
        "text": "AWS Security Blog\nImproving SPIRE security and resiliency with AWS managed services\nby\nBrendan Paul\nand\nMeg Peddada\non\n06 OCT 2026\nin\nAdvanced (300)\n,\nSecurity, Identity, & Compliance\n,\nTechnical How-to\nPermalink\nComments\nShare\nIn cloud-centered environments, establishing trust between workloads is fundamental to securing machine-to-machine communication. Traditional approaches such as API keys, shared secrets, and static service account credentials weren’t designed for the scale and ephemeral nature of cloud workloads. This drives an organizational need to shift from long-term, static credentials to short-lived cryptographic workload identities. Organizations are turning to\nSPIFFE (Secure Production Identity Framework for Everyone)\nas a core component of their workload identity strategy. SPIFFE is a set of open source standards for securely identifying software systems in dynamic and heterogeneous environments. Using SPIFFE can help address what’s known as the\nbottom turtle\nproblem: the circular dependency where protecting one credential requires yet another credential.\nSPIRE (the SPIFFE Runtime Environment)\nis an open source implementation of SPIFFE. Customers can use it to quickly experiment with the framework. However, there are operational and security considerations when deploying SPIRE in production, such as:\nWhere cryptographic signing keys for workload identities are managed\nHow to ensure availability and resiliency of the workload identity registry\nHow the SPIRE Certificate Authority integrates into the existing enterprise PKI\nHow workloads without direct connectivity to the SPIRE server validate identities\nHow workload identities are delivered to serverless environments\nHow fine-grained authorization based on SPIFFE IDs is enforced\nIn this post, we show you how to address each of these considerations by offloading SPIRE core functionality to AWS managed services. This post is accompanied by a\nGithub Repository\nthat guides you through the deployment of the reference architecture.\nTo learn the core concepts the SPIFFE framework, take a moment to familiarize yourself with the\nSPIFFE documentation\n.\nSPIRE background\nA SPIRE deployment is comprised of at least one SPIRE Server, at least one SPIRE Agent, and at least one workload.\nFigure 1: SPIRE high-level architecture\nThe\nSPIRE Server\nis deployed on a central control plane instance (or instances) and manages identity issuance and stores workload identity registrations. The SPIRE server handles five key functions:\nRegistrationAPI\n:\nCreate, update, and delete registration entries that define which workloads are entitled to specific SPIFFE IDs based on selectors (for example, Kubernetes namespace, Unix UID).\nDataStore\n: The SPIRE server uses a data store to keep track of the workload identity registration entries and the status of the SVIDs it has issued.\nKeyManager\n: Controls how the server manages private keys used to sign X.509-SVIDs and JWT-SVIDs.\nBundlePublisher\n: Publishes the local trust bundle to a store. The trust bundle is an object containing a\ntrust domain’s\ncryptographic keys\nUpstreamAuthority\n:\nDictates which root certificate authority is used to sign the SPIRE certificate authority (CA) certificate\nThe SPIRE Agent is distributed across your workloads, whether they run on\nAmazon Elastic Compute Cloud (Amazon EC2)\ninstances,\nAmazon Elastic Container Service (Amazon ECS)\ncontainers, or\nAmazon Elastic Kubernetes Service (Amazon EKS)\nPods. The SPIRE Agent handles:\nWorkloadAPI\n: Exposes the workload API to workloads, which enable workloads to retrieve their SVIDs and trust bundles from the SPIRE server.\nNodeAttestation\n: SPIRE requires that each agent attest and verify itself.\nWorkloadAttestation\n:\nThe SPIRE agent collects workload metadata to determine its identity.\nSVIDStore\n: The SPIRE Agent also stores SVIDs in other destinations, such as\nAWS Secrets Manager\nor HashiCorp Vault making them available for workloads running in serverless environments.\nAfter the server and agent are deployed, applications retrieve short-lived SPIFFE Verifiable Identity Documents (\nX.509 Certificates\nor\nJSON Web Tokens (JWTs)\n) using the workload API.\nHow to use AWS managed services for core SPIRE functions\nIn the following sections, we dive deeper into what each of these SPIRE functions does and the advantages of using each AWS service for the function.\nFigure 2: SPIFFE architecture using AWS managed services\nTo deploy the infrastructure required to follow along with this post, follow the deployment process in the\nGithub Repository\n.\nNote\n: For each managed service, there’s a parameter in the source\nAWS CloudFormation\ntemplates that you can use to specify whether to provision the resource. For example, if you already have an\nAWS Private Certificate Authority (AWS Private CA)\ncertificate authority deployed in your environment, you can use that for your SPIRE implementation and avoid provisioning a new certificate authority.\nSPIRE Key Manager using AWS KMS\nThe SPIRE Key Manager controls the cryptographic keys that are used to sign SPIFFE Verifiable Identity Documents (SVIDs), which are either X.509 certificates or JWTs.\nBy using SPIRE, you can configure the cryptographic keys to be either stored in memory or on disk, or to use a plugin where external keys are used for signing SVIDs.\nBy using the\nAWS KMS plugin for SPIRE\n, you bring the security benefits of AWS KMS to your SPIRE implementation.\nHSMs\n: AWS KMS uses hardware security modules (HSMs) that have been validated under FIPS 140-3 Level 2\nKey protection\n: Your plaintext AWS KMS keys don’t leave the HSMs, aren’t written to disk, and are only used in the volatile memory of the HSMs for the time needed to perform your requested cryptographic operation\nComprehensive auditing\n: Each request to use the keys for signing must be authenticated using Signature Version 4 (SigV4) and is audited and logged in\nAWS CloudTrail\nFine-grained access control:\nUse\nAWS KMS Key Policies\nto restrict access to your signing keys\nThis configuration block indicates to SPIRE that AWS KMS keys are used to sign our SVIDs:\nKeyManager \"aws_kms\" {\nplugin_data {\nregion = \"<your-region>\"\nkey_identifier_file = \"./key_metadata\"\n}\n}\nThis code block exists in the\nSPIRE server configuration\ndeployed in the Github repository.\nSPIRE datastore using Amazon Aurora\nThe SPIRE server uses a data store to keep track of the workload identity registration entries as well as the status of the SVIDs it has issued. By default, the datastore lives as an SQLite database in memory. However, you can configure the SPIRE server to use\nAmazon Aurora\n. By doing this, you can decouple the database from the server and offload the operational overhead of managing the datastore to AWS.\nBenefits:\nHigh availability\n: Automatic failover and multi-Availability Zone deployments\nAutomated backups\n:\nPoint-in-time recovery and automated backup retention\nScalability\n:\nScale compute and storage independently\nSecurity\n:\nEncryption at rest and in transit, with\nAWS Identity and Access Management (IAM)\nMonitoring\n:\nBuilt-in performance insights and enhanced monitoring\nReduced operational burden\n: Automated patching, maintenance, and updates\nTo do this, the CloudFormation stack provisions:\nAn Aurora PostgreSQL Cluster\nA database user with the capability to authenticate through AWS IAM\nNetwork connectivity between your SPIRE Server and the database\nAfter the sample finishes deployment, the configuration in the SPIRE server is changed from the default:\nDataStore \"sql\" {\n\nplugin_data {\n\ndatabase_type = \"sqlite3\"\n\nconnection_string = \"/opt/spire/data/server/datastore.sqlite3\"\n\n}\n\n}\nTo:\nDataStore \"sql\" {\n\nplugin_data {\n\ndatabase_type \"aws_postgres\" {\n\nregion = \"<region>\"\n\n}\n\nconnection_string = \"dbname=<dbname> user=spiffe host=<your_db_endpoint> port=<your_port>\"\n\n}\n\n}\nFor more information, see\nDatastore SQL Plugin\n.\nSPIRE certificate authority using AWS Private Certificate Authority\nThe SPIRE Server issues SVIDs to SPIRE agents and workloads. Given that these SVIDs are X.509 certificates, the SPIRE server needs to act as a certificate authority. In the default configuration of SPIRE, the server generates a self-signed certificate that it will use as the root CA certificate. In production scenarios, organizations often use their existing AWS Private CA certificate authority hierarchy.\nUsing the AWS Private CA plugin for SPIRE, you configure the SPIRE CA to act as an issuing certificate authority that chains to your existing root CA. This delivers three benefits for your SPIRE implementation:\nHSM-backed root of trust\n: The root of trust of your CA hierarchy is backed by fully managed, FIPS 140-2 Level 3 validated hardware security modules\nNon-exportable private keys\n: The private keys for the root CA can’t be exported\nFully Managed Certificate Revocation Lists and OCSP endpoint\n:\nIn case the issuing CA certificate needs to be revoked\nNote\n: If the SPIRE CA certificate will be signed by an issuing CA, you need to ensure that the\npath length\nof that CA is at least 1. The sample code provisions a root CA, so this isn’t an issue if you’re following the sample code.\nAfter the sample deployment is complete, the configuration of the SPIRE server configuration includes the\nUpstreamAuthority\nplugin to use your AWS Private CA certificate authority as the root of trust.\nUpstreamAuthority \"aws_pca\" {\n\nplugin_data {\n\nregion = \"<aws_region>\"\n\ncertificate_authority_arn = \"<your_pca_arn>\"\n\nca_signing_template_arn = \"arn:aws:acm-pca:::template/SubordinateCACertificate_PathLen0/V1\"\n\n}\n\n}\nFor more information, see the\nAWS Private CA upstream authority plugin documentation\n.\nSPIRE bundle publisher using Amazon S3\nIn SPIFFE, trust bundles are sets of public keys that are used by destination workloads to verify the identity of source workloads. These bundles contain the root certificates and public keys used to sign JWT SVIDs.\nThe SPIRE Server supports exposing an endpoint containing this trust bundle or publishing the bundle to\nAmazon Simple Storage Service (Amazon S3)\n.\nBy publishing the bundle to Amazon S3, you can:\nDecouple\n:\nDecouple bundle access from the SPIRE server availability\nContinuous validation\n: Allow destination workloads to continually validate source workload identities without requiring network access to the SPIRE server\nGlobal distribution\n: Distribute the trust bundle using\nAmazon CloudFront\n, improving performance through the CloudFront global edge network with over 750\nPoints of Presence\nReduced load\n: Offload trust bundle retrieval traffic from the SPIRE server\nVersion control\n: Maintain historical versions of trust bundles with S3 versioning\nThe following is a sample configuration for this plugin:\nBundlePublisher \"aws_s3\" {\n\nplugin_data {\n\nregion = \"<your_bucket_region>\"\n\nbucket = \"<your_bucket_name>\"\n\nobject_key = \"<your_bundle_name\"\n\nformat = \"spiffe\"\n\n}\n\n}\nFor more information, see\nS3 Bundle Publisher Plugin Reference\n.\nSPIRE Agent SVID store using Secrets Manager\nIn a typical SPIRE implementation, SVIDs are retrieved from the workload API using the SPIRE agent by workloads. In serverless or container cases, it isn’t feasible or possible to run the SPIRE agent, especially in workloads running on\nAWS Lambda\nor an AI agent running in\nAmazon Bedrock AgentCore Runtime\n. In these scenarios, use the\nSVID store plugin\nto push the SVID to\nSecrets Manager\n.\nIn this scenario, you still need a SPIRE agent running on a node that performs node attestation with the SPIRE server and delivers the SVID to a secrets store. One of the available secrets store plugins is the\nAWS Secrets Manager SVIDStore Plugin\n.\nBenefits:\nEncryption at rest\n: Secrets are encrypted by default using AWS managed or customer-managed AWS KMS keys\nBroad integration\n: Integrations with multiple compute types, including\nAWS Secrets Manager Lambda Extension\n,\nAmazon ECS\n,\nAmazon EMR\n, and\n52\nother AWS services\nClient-side caching\n: Secrets Manager provides\nclient-side caching libraries\nto improve performance and reduce API calls\nMulti-region replication\n: Built-in\nmulti-Region replication functionality\nfor workloads with multi-region requirements\nFine-grained access control\n: Use resource policies to control which workloads access which SVIDs\nAudit trail\n: All secret access is logged in CloudTrail\nThis plugin is configured in the\nagent\n, as opposed to the SPIRE server. A reference for the specific permissions required are in the\nplugin Github repository\n. In the sample code, see the configuration in the following\nagent.conf\nfile:\nSVIDStore \"aws_secretsmanager\" {\n\nplugin_data {\n\nregion = \"<your_region>\"\n\n}\n\n}\nWhen you need to specify a given workload’s SVID to be pushed to Secrets Manager, you add the\nstoreSVID\nand selector parameters when you create the entry in the workload registry. If you’re managing your SPIRE server in Kubernetes, the appropriate command looks like:\nkubectl exec -n spire spire-server-<postfix>-- \\\n\n/opt/spire/bin/spire-server entry create \\\n\n-spiffeID spiffe://example.org/<workload_name> \\\n\n-parentID spiffe://example.org/ns/spire/sa/spire-agent \\\n\n-selector aws_secretsmanager:secretname:<workload_name> \\\n\n-storeSVID\nFine-grained access control using Verified Permissions\nUp to this point, all the managed services we’ve talked about have been used for creating and distributing SVIDs and trust bundles to workloads. However, a key advantage of using a framework such as SPIFFE is that it allows resource owners to protect resources with fine-grained access control. One managed service that helps you do that in the context of SPIFFE and SPIRE implementations is\nAmazon Verified Permissions\n.\nVerified Permissions is a scalable, fine-grained permissions management and authorization service that helps you build secure applications. You can use it to:\nDefine declarative policies\n: Use\nCedar policy language\n, which provides human-readable, declarative access control rules\nCentralize policy management\n: Separate authorization logic from application code\nTake advantage of\nthe straightforward policy authoring,\nformal verification capabilities,\nand\nperformance benefits\nof Cedar\nMake real-time decisions\n: Evaluate authorization requests in real-time based on multiple factors including user identity, workload identity (SPIFFE ID), resource attributes, and contextual information\nIntegrate with identity providers\n: Support for OpenID Connect (OIDC) providers, enabling validation of JWT tokens including JWT-SVIDs\nWith Verified Permissions, you authenticate SPIRE issued SVIDs using the public keys associated with your trust domain, and deploy fine-grained authorization policies protecting your resources. To use Verified Permissions, you need a\npolicy store,\nan\nidentity source\n, and\nauthorization policies\n.\nThe\ngithub sample\ncreates a policy store on your behalf and sets up the necessary infrastructure to have SPIRE serve as an identity source for your policy store.\nYou will need policies to enforce fine grained authorization. The following sample policy forbids a specific workload from taking any action:\nforbid(\n\nprincipal,\n\naction,\n\nresource\n\n)\n\nwhen {\n\ncontext has sub &&\n\ncontext.sub like \"spiffe://example.org/forbidden-workload/*\"\n\n};\nOr conversely allows a specific workload to take actions:\npermit(\n\nprincipal,\n\naction,\n\nresource\n\n)\n\nwhen {\n\ncontext has sub &&\n\ncontext.sub like \"spiffe://example.org/allowed-workload/*\"\n\n};\nExperiment with these policies as you build on top of your SPIRE infrastructure.\nConclusion\nThis post demonstrates how organizations enhance their SPIRE deployments on AWS by replacing default implementations with AWS managed services. We showed you integrations with AWS KMS for SVID signing, Amazon RDS Aurora for managed datastore operations, AWS Private Certificate Authority for root of trust, Amazon S3 and CloudFront for global trust bundle distribution, AWS Secrets Manager for SVID storage, and Amazon Verified Permissions for fine-grained authorization. By adopting these integrations, organizations can improve security posture, reduce operational complexity, and enhance resiliency.\nIf you’re interested in learning SPIFFE on AWS, check out our\nSPIRE on AWS github sample\nor the\nSPIFFE and SPIRE on AWS Workshop\nfor hands-on learning.\nIf you have feedback about this post, submit comments in the\nComments\nsection below.\nBrendan Paul\nBrendan is a Security Services SA Manager at AWS and has been at AWS for more than 7 years. He spends most of his time at work helping customers solve problems in the data protection and workload identity domains. Outside of work, he’s pursuing his master’s degree in data science from UC Berkeley.\nMeg Peddada\nMeg is a Principal FSI Security Solutions architect specializing in security, risk, and compliance. Her expertise spans governance, security automations, threat management, and architecture. In her spare time, she loves playing volleyball, arts and crafts, and finding new brunch experiences.\nTAGS:\nSecurity Blog\nLoading comments…",
        "metadata": {
          "viewport": "width=device-width, initial-scale=1",
          "robots": "index, follow",
          "og:locale": "en_US",
          "og:site_name": "Amazon Web Services",
          "og:title": "Improving SPIRE security and resiliency with AWS managed services | Amazon Web Services",
          "og:type": "article",
          "og:url": "https://aws.amazon.com/blogs/security/improving-spire-security-and-resiliency-with-aws-managed-services/",
          "og:description": "In cloud-centered environments, establishing trust between workloads is fundamental to securing machine-to-machine communication. Traditional approaches such as API keys, shared secrets, and static service account credentials weren’t designed for the scale and ephemeral nature of cloud workloads. This drives an organizational need to shift from long-term, static credentials to short-lived cryptographic workload identities. Organizations are […]",
          "og:image": "https://d2908q01vomqb2.cloudfront.net/22d200f8670dbdb3e253a90eee5098477c95c23d/2026/10/06/SPIRE-pic.jpg",
          "og:image:width": "1000",
          "og:image:height": "500",
          "og:updated_time": "2026-10-06T12:42:41-07:00",
          "article:publisher": "https://www.facebook.com/amazonwebservices",
          "article:section": "Advanced (300)",
          "article:tag": "Security Blog",
          "article:published_time": "2026-10-06T11:52:25-07:00",
          "article:modified_time": "2026-10-06T12:42:41-07:00",
          "twitter:card": "summary_large_image",
          "twitter:site": "@awscloud",
          "twitter:domain": "https://aws.amazon.com/blogs/",
          "twitter:title": "Improving SPIRE security and resiliency with AWS managed services | Amazon Web Services",
          "twitter:description": "In cloud-centered environments, establishing trust between workloads is fundamental to securing machine-to-machine communication. Traditional approaches such as API keys, shared secrets, and static service account credentials weren’t designed for the scale and ephemeral nature of cloud workloads. This drives an organizational need to shift from long-term, static credentials to short-lived cryptographic workload identities. Organizations are […]",
          "twitter:image": "https://d2908q01vomqb2.cloudfront.net/22d200f8670dbdb3e253a90eee5098477c95c23d/2026/10/06/SPIRE-pic.jpg",
          "inLanguage": "en-US",
          "image": "https://d2908q01vomqb2.cloudfront.net/22d200f8670dbdb3e253a90eee5098477c95c23d/2026/10/06/SPIRE-pic.jpg"
        },
        "extraction": "article/main",
        "verified": false
      }
    },
    {
      "title": "Identity-aware AI data agents with AWS Lake Formation and Trusted Identity Propagation",
      "url": "https://aws.amazon.com/blogs/security/identity-aware-ai-data-agents-with-aws-lake-formation-and-trusted-identity-propagation",
      "source": "AWS Security",
      "published": "2026-10-07T00:07:06+08:00",
      "excerpt": "You’re building a data agent that lets business users ask questions about lakehouse data in natural language. You’ve already built governance policies that control who can access which datasets. The challenge is making the agent respect those rules without rebuilding them in your application code. When a user asks a question, the agent maps it […]",
      "topics": [
        "ai_agent"
      ],
      "is_new": false,
      "first_seen": "2026-10-07T17:38:33.161622+08:00",
      "article": {
        "ok": true,
        "final_url": "https://aws.amazon.com/blogs/security/identity-aware-ai-data-agents-with-aws-lake-formation-and-trusted-identity-propagation/",
        "text": "AWS Security Blog\nIdentity-aware AI data agents with AWS Lake Formation and Trusted Identity Propagation\nby\nThiyagarajan Mani\n,\nMihir Borkar\n,\nPhilippe Duplessis-Guindon\n, and\nUmang Khambhalikar\non\n06 OCT 2026\nin\nAdvanced (300)\n,\nAWS IAM Identity Center\n,\nAWS Lake Formation\n,\nSecurity, Identity, & Compliance\n,\nTechnical How-to\nPermalink\nComments\nShare\nYou’re building a data agent that lets business users ask questions about lakehouse data in natural language. You’ve already built governance policies that control who can access which datasets. The challenge is making the agent respect those rules without rebuilding them in your application code.\nWhen a user asks a question, the agent maps it to data and constructs a query. The tool runs under its own\nAWS Identity and Access Management (IAM)\nrole, so\nAWS Lake Formation\nsees the tool’s credentials, not the person behind the request. This leaves you with two inadequate options: restrict tool access (limiting self-service analytics) or rebuild access controls in application code (moving governance out of the data layer).\nIn this post, we show you a different approach: identity-aware AI data agents that propagate each user’s identity through every hop, from the user, through the agent, into the tool, so Lake Formation evaluates the user’s grants. Your application code makes no authorization decisions, existing Lake Formation policies work without modifications, and\nAWS CloudTrail\nrecords the actual person who accessed the data.\nIn this post, you learn how to:\nSet up per-user data access controls for AI agents querying your lakehouse without rewriting your existing Lake Formation governance policies by configuring\nAmazon Bedrock AgentCore\nto carry each user’s identity through trusted identity propagation (TIP).\nEnsure auditability and compliance by performing a server-side token exchange inside\nAWS Lambda\nthat converts the identity token into Lake Formation credentials scoped to the real user, with CloudTrail recording every query.\nValidate the pattern end-to-end by testing with multiple users and confirming per-user query results and CloudTrail audit evidence.\nThe building blocks in this post, OAuth 2.0 token delegation,\nAWS IAM Identity Center\n, Lake Formation, and Lambda are well-documented individually. The new constraint is that a foundation model (FM) now sits in the middle of the propagation chain. The FM is the agent’s brain, it decides which tools to call and what arguments to pass and anything that enters its context (prompts, tool schemas, arguments) is accessible within that trust boundary. So, the user’s identity token must reach the tool, but it must do so on the HTTP transport layer, bypassing the FM’s reasoning layer entirely. This post demonstrates the three\nAmazon Bedrock AgentCore\nconfigurations that achieve that.\nWhether you’re building agents on Strands, LangGraph, or a similar framework, this post gives you a deployable pattern on Amazon Bedrock AgentCore. Security engineers will find the identity-transport and audit properties relevant, and data platform owners will see how existing Lake Formation grants extend to AI workloads with no changes.\nSolution overview\nFigure 1: Solution overview\nWith this pattern (shown in Figure 1), your data agent can query Lake Formation governed data with per-user access controls, full CloudTrail audit trails, and no changes to your existing governance policies. Here’s how it works.\nTwo tokens travel through the system. An\naccess_token\nauthenticates the request at each trust boundary (\nBedrock AgentCore Runtime\n,\nBedrock AgentCore Gateway\n). An\nid_token\ncarries your identity and is exchanged, server-side, for the identity context that Lake Formation evaluates.\nA separate TIP role carries only the IAM permissions needed to call service APIs, it has no Lake Formation data grants.\nLake Formation evaluates only the propagated user identity, not the TIP role.\nThe request flow is:\nUser to UI:\nThe user authenticates with an OpenID Connect (OIDC) identity provider (IdP). This post uses\nAmazon Cognito\n, but you can use any OIDC provider, such as Okta. The UI receives an\nid_token\nand an\naccess_token\n.\nUI to Bedrock AgentCore Runtime:\nThe UI calls the agent running in AgentCore Runtime over HTTPS. The\naccess_token\ngoes in the standard\nAuthorization\nheader. The\nid_token\ngoes in a custom header:\nX-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken\n. The HTTP body contains only the user’s prompt.\nAgentCore Runtime to agent code:\nThe runtime validates the\naccess_token\nagainst the configured JSON Web Token (JWT) authorizer, then passes the request to the agent container with both headers accessible through\ncontext.request_headers\n.\nAgent to Bedrock AgentCore Gateway:\nThe agent opens a Model Context Protocol (MCP) connection to an AgentCore gateway, including both headers on the connection. The AgentCore gateway validates the\naccess_token\nand forwards the custom header to its Lambda target.\nAgentCore Gateway to Lambda:\nThe propagated headers arrive in\ncontext.client_context.custom[‘bedrockAgentCorePropagatedHeaders’]\n.\nLambda to the data layer:\nLambda validates the\nid_token\n, exchanges it for an identity context, assumes a role with that context, and runs the\nAmazon Athena\nquery under the user’s identity.\nLake Formation evaluates grants against the real user. Athena returns only the rows and columns that the user is entitled to see. CloudTrail records the assumed role with an\nonBehalfOf\nentry identifying the human.\nNow that you’ve seen the end-to-end flow, the following sections walk through each piece, starting with what you need to have in place before you build.\nPrerequisites\nThis post assumes you have the working knowledge of OAuth 2.0, IAM, and Lake Formation grants.\nAn\nIAM Identity Center\ninstance with a\ntrusted token issuer (TTI)\nconfigured to accept your OIDC IdP’s tokens.\nAn OAuth Application in IAM Identity Center configured for\nCreateTokenWithIAM\nwith the JWT Bearer grant.\nLake Formation\ngoverning your\nAWS Glue\nData Catalog, with grants already assigned to users or groups.\nAn Athena workgroup and an\nAmazon Simple Storage Service (Amazon S3)\nbucket for query results.\nAn OIDC IdP. The reference implementation uses\nAmazon Cognito\nas the demo IdP, but the pattern is IdP-agnostic. Auth0, Microsoft Entra ID, Okta, Ping, or any OIDC-compliant provider works identically, if your TTI accepts its tokens.\nThis post doesn’t walk through setting up any of these components. The existing AWS documentation covers each one. For more information, see the links in the preceding list and the related resources at the end of this post.\nThe three Bedrock AgentCore configuration steps\nThree Bedrock AgentCore features make this pattern work. Together they form the chain of custody for the user’s\nid_token\nfrom the moment it arrives at the Bedrock AgentCore Runtime to the moment Lambda uses it.\nConfigure the runtime request header allow list\nBedrock AgentCore Runtime doesn’t pass request headers into the agent container by default. You opt in by declaring an allow list, either through\nagentcore configure\nor directly in the runtime configuration:\n# .bedrock_agentcore.yaml\n\nrequest_header_configuration:\n\trequestHeaderAllowlist:\n\t\t- Authorization\n\t\t- X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken\nAgentCore Runtime supports two types of forwarded headers:\nThe standard\nAuthorization\nheader for OAuth inbound JWT authentication (\naccess_token\n), and\nCustom headers prefixed with\nX-Amzn-Bedrock-AgentCore-Runtime-Custom-\nThe\nid_token\nin this pattern uses a custom header. Inside the agent, the allow listed headers arrive as a dictionary object on the request context.\nThe following Python code runs in the agent container:\nfrom bedrock_agentcore.runtime import BedrockAgentCoreApp\n \nID_TOKEN_HEADER = \"X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken\"\napp = BedrockAgentCoreApp()\n \n@app.entrypoint\ndef invoke(payload, context):\n    request_headers = getattr(context, \"request_headers\", None) or {}\n \n    id_token = \"\"\n    access_token = \"\"\n    for key, value in request_headers.items():\n        if key.lower() == ID_TOKEN_HEADER.lower():\n            id_token = value\n        elif key.lower() == \"authorization\":\n            access_token = value.replace(\"Bearer \", \"\")\n \n    # ... build MCP headers and call the Gateway\nThe agent code reads the\nid_token\nfrom the HTTP transport and forwards it (also on the HTTP transport) to the next hop. It doesn’t treat the token as a tool argument and doesn’t inject it into a prompt.\nKey takeaway:\nThe runtime allow list is the first gate. Without it, the\nid_token\ndoesn’t reach your agent code.\nConfigure AgentCore Gateway metadata for header propagation\nAn AgentCore Gateway is the Model Context Protocol (MCP) endpoint the agent talks to. When AgentCore Gateway invokes a Lambda target, it doesn’t forward arbitrary request headers by default. You configure which headers to propagate using\nmetadataConfiguration.allowedRequestHeaders\non the target:\nfrom aws_cdk import aws_bedrockagentcore as agentcore\n \nself.gateway_target = agentcore.CfnGatewayTarget(\n    self, \"AthenaTarget\",\n    name=\"athena-executor\",\n    gateway_identifier=self.gateway.attr_gateway_identifier,\n    target_configuration=agentcore.CfnGatewayTarget.TargetConfigurationProperty(\n        mcp=agentcore.CfnGatewayTarget.McpTargetConfigurationProperty(\n            lambda_=agentcore.CfnGatewayTarget.McpLambdaTargetConfigurationProperty(\n                lambda_arn=lambda_function_arn,\n                tool_schema=...  # execute_athena_query\n            ),\n        ),\n    ),\n    metadata_configuration=agentcore.CfnGatewayTarget.MetadataConfigurationProperty(\n        allowed_request_headers=[\"X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken\"],\n    ),\n    ...\n)\nNotice that the tool schema doesn’t include an\nid_token\nparameter; there’s no token parameter on any tool. The FM doesn’t see, select, or pass an\nid_token\nbecause the token isn’t part of the tool’s contract. It travels parallel to the tool call, on the HTTP connection, through\nmetadataConfiguration\n.\nThis is a critical property for security. If you put the\nid_token\nin the tool schema instead, the FM becomes responsible for passing it, which means the token lands in prompts, traces, memory, and logs. Keeping the token off the tool contract keeps it out of the FM entirely.\nKey takeaway:\nThe\nmetadataConfiguration\nof the AgentCore gateway is the second gate. It controls which headers cross from the agent into the Lambda function without touching the tool schema.\nRead propagated headers in Lambda\nOn the Lambda side, the propagated header arrives not in the event body but in the client context, under a specific key.\nThe following Python code runs in the Lambda function:\nID_TOKEN_HEADER = \"X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken\"\n \ndef lambda_handler(event, context):\n    client_ctx = getattr(context.client_context, \"custom\", {}) or {}\n    propagated_headers = client_ctx.get(\"bedrockAgentCorePropagatedHeaders\", {})\n    id_token = propagated_headers.get(ID_TOKEN_HEADER)\n \n    if not id_token:\n        return {\"statusCode\": 400, \"body\": {\"error\": \"missing id_token\"}}\n \n    # Tool arguments from the agent's call (no id_token here)\n    query = event[\"query\"]\n    database = event[\"database\"]\n    workgroup = event[\"workgroup\"]\n    output_location = event[\"output_location\"]\n \n    # ... validate token, exchange, run query\nThe event dictionary contains the tool’s declared parameters and nothing else. You reach the\nid_token\nonly through\ncontext.client_context.custom[‘bedrockAgentCorePropagatedHeaders’]\n. That’s the handoff point.\nKey takeaway:\nThe\nid_token\narrives through the client context rather than tool arguments; the FM has no access to it. The Lambda is the only component that reads the token.\nPerform the server-side token exchange\nAfter Lambda has the\nid_token\n, it validates the token and exchanges it for an\nidentityContext\n. This step uses standard IAM Identity Center TIP mechanics. That it happens inside Lambda rather than anywhere else is what keeps the identity context from crossing a process boundary.\nimport boto3, jwt, time\n \ndef exchange_and_assume(id_token: str, user_sub: str):\n    # 1. Validate id_token against the OIDC IdP's JWKS.\n    claims = validate_id_token(id_token)  # signature, exp, aud, iss, token_use\n \n    # 2. Exchange for an Identity Center identityContext.\n    sso_oidc = boto3.client(\"sso-oidc\")\n    resp = sso_oidc.create_token_with_iam(\n        clientId=OAUTH_APPLICATION_ARN,\n        grantType=\"urn:ietf:params:oauth:grant-type:jwt-bearer\",\n        assertion=id_token,\n    )\n    identity_context = resp[\"awsAdditionalDetails\"][\"identityContext\"]\n \n    # 3. AssumeRole with ProvidedContexts\n    sts = boto3.client(\"sts\")\n    assumed = sts.assume_role(\n        RoleArn=TIP_ROLE_ARN,\n        RoleSessionName=f\"agent-tip-{user_sub[:8]}-{int(time.time())}\",\n        ProvidedContexts=[{\n            \"ProviderArn\": \"arn:aws:iam::aws:contextProvider/IdentityCenter\",\n            \"ContextAssertion\": identity_context,\n        }],\n    )\n    creds = assumed[\"Credentials\"]\n    return boto3.Session(\n        aws_access_key_id=creds[\"AccessKeyId\"],\n        aws_secret_access_key=creds[\"SecretAccessKey\"],\n        aws_session_token=creds[\"SessionToken\"],\n    )\nTwo properties come out of this exchange:\nThe\nidentityContext\nis created and consumed inside a single Lambda invocation. It doesn’t get returned to the agent, the gateway, or the UI.\nThe resulting\nboto3.Session\nholds short-lived credentials whose underlying identity assertion is the real user. When the session calls Athena, the query runs with the user’s identity propagated. Lake Formation sees the user, not the Lambda function’s role.\nEverything after this, including the Athena query and result formatting, is standard boto3.\nConfigure Lake Formation grants\nYou need one grant to the IAM Identity Center user or group. That’s the whole story at the Lake Formation layer.\naws lakeformation grant-permissions \\\n  --principal DataLakePrincipalIdentifier=arn:aws:identitystore:::user/<USER_ID> \\\n  --resource '{\"Table\":{\"DatabaseName\":\"iceberg_db\",\"Name\":\"trip_details\"}}' \\\n  --permissions SELECT\nThis is the grant Lake Formation evaluates at query time. You add column-level and row-level filters to the same user or group the same way. Nothing here is aware of or specific to AI agents. If you already have a Lake Formation grants model for human users, you already have the grants this pattern needs.\nUnderstanding the TIP role:\nThe TIP role that Lambda assumes has no Lake Formation data grants. It holds only IAM permissions to call the service APIs:\nathena:*\nfor query runs,\nglue:*\nfor catalog reads,\nlakeformation:GetDataAccess\nfor the query plan handshake, and Amazon S3 access for the Athena output bucket. When Lambda assumes this role with an\nidentityContext\nattached through\nProvidedContexts\n, Lake Formation evaluates only the propagated user identity against its grants. The role itself is transparent to the authorization decision.\nIn the more common\nagent runs as a role\npattern, the role carries the grants, which is why per-user governance breaks. Here the role carries no grants; it’s a session vehicle, not an authorization subject.\nTest the pattern end-to-end\nTwo users, same question, different outcomes.\nUser A has\nSELECT\non\ntrip_details\n. They ask the agent for five records from the table.\nFigure 2: Five records are requested and returned by the agent\nUser B has no grant on\ntrip_details\n. They ask the same question.\nFigure 3: User doesn’t have access to the data\nNo code changed between the two interactions. No parameter was toggled. Lake Formation made the decision based on the propagated identity.\nThe CloudTrail record for the\nAssumeRole\ncall shows the delegation:\n{\n  \"eventSource\": \"sts.amazonaws.com\",\n  \"eventName\": \"AssumeRole\",\n  \"requestParameters\": {\n    \"roleArn\": \"arn:aws:iam::<ACCOUNT_ID>:role/<TIP_ROLE_NAME>\",\n    \"roleSessionName\": \"agent-tip-<user_sub_prefix>-<timestamp>\",\n    \"providedContexts\": [{\n      \"providerArn\": \"arn:aws:iam::aws:contextProvider/IdentityCenter\",\n      \"contextAssertion\": \"<identity-context-assertion>\"\n    }]\n  },\n  \"userIdentity\": {\n    \"type\": \"AssumedRole\",\n    \"onBehalfOf\": {\n      \"userId\": \"<IDENTITY_STORE_USER_ID>\",\n      \"identityStoreArn\": \"arn:aws:identitystore::<ACCOUNT_ID>:identitystore/<ID>\"\n    }\n  }\n}\nThe\nonBehalfOf\nblock closes the audit loop. Each query the agent runs on a user’s behalf has a CloudTrail record naming that user, with no additional instrumentation in your code.\nSecurity properties\nFour properties follow from this architecture. These are the core value propositions of the identity-aware pattern:\nThe id_token never reaches the foundation model:\nIt travels on HTTP headers at every hop, and Lambda reads it from\ncontext.client_context.custom\n. It’s not a parameter on any tool. The FM has no path to it: not in tool arguments, not in prompts, not in memory, not in traces.\nThe identity context stays inside a single Lambda invocation:\nIt’s derived from the\nid_token\n, used immediately in an\nAssumeRole\ncall, and discarded. It doesn’t go back to the agent, the gateway, or the UI.\nAuthorization decisions live in Lake Formation, against the real user only:\nThe TIP role the Lambda function assumes has no data grants. Lake Formation evaluates the propagated user identity. No code path in the agent, gateway, or Lambda function performs authorization logic.\nThe audit trail requires no extra work:\nThe CloudTrail\nAssumeRole\nevent with\nonBehalfOf\nidentifies the human user for every query. You get the same audit fidelity you would have for human users accessing data directly.\nDeploy the pattern\nTo deploy this pattern, you need to configure four things:\nAn OIDC IdP with a TTI in IAM Identity Center accepting its tokens, and an Identity Center OAuth Application configured for\nCreateTokenWithIAM\n.\nBedrock AgentCore Runtime running your agent container with\nrequestHeaderAllowlist\ncovering\nAuthorization\nand your custom\nid_token\nheader.\nBedrock AgentCore Gateway with a Lambda target whose\nmetadataConfiguration.allowedRequestHeaders\nincludes the\nid_token\nheader. The Lambda target’s tool schema has no\nid_token\nparameter.\nLambda reading the\nid_token\nfrom\ncontext.client_context.custom[‘bedrockAgentCorePropagatedHeaders’]\n, performing the token exchange through\nsso-oidc:CreateTokenWithIAM\n, and calling\nsts:AssumeRole\nwith\nProvidedContexts\nto get the TIP-bearing session.\nConclusion\nWhen an AI agent queries a governed lakehouse, the data layer needs to know who’s asking, not which role the agent is running under. This post showed you how to resolve that by treating the agent as an OAuth delegated actor. The user’s token travels alongside the agent’s HTTP transport but doesn’t enter the model’s context, and the token exchange that produces query-time credentials happens server-side inside Lambda, scoped to a single invocation.\nThe three Bedrock AgentCore features that make this composable (\nrequestHeaderAllowlist\non runtime,\nmetadataConfiguration.allowedRequestHeaders\non gateway, and\nbedrockAgentCorePropagatedHeaders\non Lambda) are specific to building on Bedrock AgentCore. Everything downstream of Lambda is IAM Identity Center and Lake Formation functionality.\nIf you’re building agents that read governed data, you don’t have to choose between a single over-permissioned service role and per-user code paths. The identity the data layer evaluates can be the real user, the audit trail can name the real user, and the foundation model doesn’t need to know the user’s token exists.\nThe result is a clean separation: the user’s identity travels end-to-end, the model never sees it, and the data layer enforces it exactly as if the user queried directly.\nRelated resources\nTrusted Identity Propagation with AWS IAM Identity Center\nAWS Lake Formation User Guide\nAmazon Bedrock AgentCore Runtime custom headers\nAmazon Bedrock AgentCore Gateway header propagation\nRFC 7523 – JWT Bearer Profiles for OAuth 2.0\nAmazon Bedrock AgentCore Runtime A2A protocol contract\nIf you have feedback about this post, submit comments in the\nComments\nsection below.\nThiyagarajan Mani\nThiyagarajan is a Sr. Delivery Consultant at AWS. With over 20 years of experience, he architects modern data platforms spanning lakehouses, ingestion pipelines, and generative and agentic AI applications. He specializes in transforming legacy data ecosystems into scalable, cloud-centered architectures that unlock advanced analytics and intelligent automation for customers. Outside work, he enjoys time with family and riding bikes.\nMihir Borkar\nMihir is a Senior Solutions Architect at AWS, partnering with ISVs to build and scale their platforms. With a decade of experience across data architecture and delivery, his background in enterprise-scale engagements gives him a builder’s perspective, bridging architecture strategy with practical implementation. Outside work, he explores the latest developments in cloud technologies and AI/ML.\nPhilippe Duplessis-Guindon\nPhilippe is a Delivery Consultant at AWS, where he has worked on a wide range of generative AI projects, touching on most aspects from infrastructure and DevOps to software development and AI/ML. After earning his bachelor’s in software engineering and a master’s in computer vision and machine learning from Polytechnique Montréal, he joined AWS to help customers accelerate their generative AI journeys.\nUmang Khambhalikar\nUmang is a Senior Consultant at AWS Professional Services, specializing in data and AI. He helps enterprise customers design and implement secure, governed data platforms and agentic AI solutions using services like Amazon Bedrock AgentCore, AWS Lake Formation, and AWS Glue. Umang brings over 19 years of IT consulting experience to solving complex challenges at the intersection of security, data governance, and generative AI.\nTAGS:\nAWS IAM Identity Center\n,\nAWS Lake Formation\n,\nSecurity Blog\nLoading comments…",
        "metadata": {
          "viewport": "width=device-width, initial-scale=1",
          "robots": "index, follow",
          "og:locale": "en_US",
          "og:site_name": "Amazon Web Services",
          "og:title": "Identity-aware AI data agents with AWS Lake Formation and Trusted Identity Propagation | Amazon Web Services",
          "og:type": "article",
          "og:url": "https://aws.amazon.com/blogs/security/identity-aware-ai-data-agents-with-aws-lake-formation-and-trusted-identity-propagation/",
          "og:description": "You’re building a data agent that lets business users ask questions about lakehouse data in natural language. You’ve already built governance policies that control who can access which datasets. The challenge is making the agent respect those rules without rebuilding them in your application code. When a user asks a question, the agent maps it […]",
          "og:image": "https://d2908q01vomqb2.cloudfront.net/22d200f8670dbdb3e253a90eee5098477c95c23d/2026/09/30/Main-image-2.jpg",
          "og:image:width": "1200",
          "og:image:height": "600",
          "og:updated_time": "2026-10-06T09:07:06-07:00",
          "article:publisher": "https://www.facebook.com/amazonwebservices",
          "article:section": "Advanced (300)",
          "article:tag": "Security Blog",
          "article:published_time": "2026-10-06T09:07:06-07:00",
          "article:modified_time": "2026-10-06T09:07:06-07:00",
          "twitter:card": "summary_large_image",
          "twitter:site": "@awscloud",
          "twitter:domain": "https://aws.amazon.com/blogs/",
          "twitter:title": "Identity-aware AI data agents with AWS Lake Formation and Trusted Identity Propagation | Amazon Web Services",
          "twitter:description": "You’re building a data agent that lets business users ask questions about lakehouse data in natural language. You’ve already built governance policies that control who can access which datasets. The challenge is making the agent respect those rules without rebuilding them in your application code. When a user asks a question, the agent maps it […]",
          "twitter:image": "https://d2908q01vomqb2.cloudfront.net/22d200f8670dbdb3e253a90eee5098477c95c23d/2026/09/30/Main-image-2.jpg",
          "inLanguage": "en-US",
          "image": "https://d2908q01vomqb2.cloudfront.net/22d200f8670dbdb3e253a90eee5098477c95c23d/2026/09/30/Main-image-2.jpg"
        },
        "extraction": "article/main",
        "verified": false
      }
    },
    {
      "title": "Managed Apache Iceberg at scale: How Spanner powers Lakehouse runtime catalog",
      "url": "https://cloud.google.com/blog/products/data-analytics/lakehouse-runtime-catalog-powered-by-spanner",
      "source": "Google Cloud · Agent 身份",
      "published": "2026-10-07T00:00:00+08:00",
      "excerpt": "As customers modernize to lakehouse architectures, they are standardizing on open formats such as Apache Iceberg to create a shared data estate across compatible engines. This enables you to build AI-native lakehouses that turn data to semantic knowledge, enable proactive action, and operate at an agentic scale. One of the key components of a lakehouse is the catalog, and in the Apache Iceberg environment, that usually means the Iceberg REST Catalog. An Apache Iceberg catalog is responsible for maintaining table pointers, handling atomic commits, and serving as the single source of truth for table locations. But as large enterprise organizati",
      "topics": [
        "ai_agent"
      ],
      "is_new": false,
      "first_seen": "2026-10-07T17:38:33.161622+08:00",
      "article": {
        "ok": true,
        "final_url": "https://cloud.google.com/blog/products/data-analytics/lakehouse-runtime-catalog-powered-by-spanner",
        "text": "Data Analytics\nManaged Apache Iceberg at scale: How Spanner powers Lakehouse runtime catalog\nOctober 7, 2026\nVinod Ramachandran\nProduct Manager\nMina Mikhail\nSoftware Engineering Manager\nTry Gemini Enterprise today\nThe front door to AI in the workplace\nTry now\nAs customers modernize to lakehouse architectures, they are standardizing on open formats such as Apache Iceberg to create a shared data estate across compatible engines. This enables you to build AI-native lakehouses that turn data to semantic knowledge, enable proactive action, and operate at an agentic scale.\nOne of the key components of a lakehouse is the catalog, and in the Apache Iceberg environment, that usually means the Iceberg REST Catalog. An Apache Iceberg catalog is responsible for maintaining table pointers, handling atomic commits, and serving as the single source of truth for table locations. But as large enterprise organizations modernize to lakehouses, they have begun to realize that they need a highly scalable and available managed catalog as a part of their lakehouse architecture. This becomes even more important as querying scales with agents. To support a large amount of repeated small queries from agents, you will need to build on top of a managed catalog that provides atomicity, consistency, availability and concurrency at massive scale.\nIn this blog, we explore the challenges a managed catalog faces in modern cloud environments at agent scale, and show you how Google Cloud’s serverless\nLakehouse runtime catalog\ncan help address them. Powered by\nSpanner\n, Google Cloud’s always-on database with virtually unlimited scale, and built to meet the open Apache Iceberg REST catalog specification, the Lakehouse runtime catalog is the highly scalable and available foundation you need for the agentic era.\nChallenges a managed catalog needs to solve in the Lakehouse\nWhen speaking with data engineers and infrastructure leads running production analytics at scale in a Lakehouse, the following core pain points consistently emerge and need to be solved by a managed catalog:\nAtomic commits and concurrency control:\nIceberg guarantees ACID transactions via optimistic concurrency control (OCC). A managed catalog must implement a bulletproof atomic compare-and-swap (CAS) operation to swap the current metadata pointer.\nHigh availability and operational maintenance:\nBecause queries fail immediately if the catalog is down, a managed catalog becomes a critical Tier-1 service.\nScaling the database backing the catalog:\nCatalog architects typically face a difficult trade-off when choosing a backing database for table metadata and state. Traditional scale-up relational databases provide SQL and ACID transactions, but hit vertical CPU, memory, storage and connection limits under heavy concurrent read/write loads unless manually sharded which incurs a huge operational overhead; while scale-out database systems are either eventually consistent, hard to manage, not enterprise-ready, or all of the above.\nTable maintenance coordination:\nA catalog alone does not optimize data; you must build and operate ancillary pipelines for compaction, snapshot expiration, manifest rewriting, and orphan file cleanup.\nGovernance and security:\nA catalog acts as the security gatekeeper. The catalog must implement and maintain:\nAuthentication protocols (e.g., OAuth2 token exchange, IAM federation)\nAccess control down to namespace and table levels\nVended storage credentials (e.g., generating short-lived tokens so query engines don't need broad, direct storage credentials)\nLakehouse runtime catalog\nTo solve these challenges, we built the Lakehouse runtime catalog (GA) with support for Iceberg Rest Catalog. The Lakehouse runtime catalog is a fully serverless, highly available, and unified metadata registry designed from the ground up to support modern open table formats like\nApache Iceberg. By natively implementing the Apache Iceberg REST Catalog specification\n,\nthe Lakehouse runtime catalog decouples metadata discovery from compute engines, helping ensure multiple Iceberg-compatible engines can access a shared data estate and enabling you to take your workloads to production sooner. We’ve helped many customers streamline the migration of their managed catalogs. For example,\nEtsy\nmigrated its catalog to Lakehouse runtime catalog, joining data in place to accelerate pipeline queries by 60%.\nThis approach offers a number of architectural benefits:\nOpen APIs\n: Support for Iceberg Rest Catalog enables different teams to use their preferred analytics tools on a single, unified dataset.\nMulti-engine interoperability\n: Once registered, tables are immediately discoverable and queryable across Google Cloud Managed Service for Apache Spark, BigQuery, and open-source engines via standard REST interfaces.\nRead/write interoperability\nfor Iceberg tables:\nLeverage Iceberg-compatible engines such as BigQuery, Managed Spark to write to Iceberg tables registered in the Lakehouse runtime catalog. Customers can also use Managed Spark to write to Iceberg tables in external catalogs.\nFully managed Iceberg storage with enterprise-grade features:\nUse Google's\ndifferentiated infrastructure\nto run analytics with performance on Iceberg tables. This gives you the benefits of open-source flexibility plus performance, scale, governance, and multimodal processing.\nZero data copy\n: Table definitions point directly to your existing data in the underlying object store. You do not move, rewrite, or duplicate your underlying data.\nBi-directional catalog federation\nacross clouds:\nAccess data from\nDatabricks Unity\n,\nSnowflake Horizon\nand\nAWS Glue\nwith support for vended credentials and OIDC token exchange. This lets you bring Google AI\ndirectly to your AWS and Azure data\n.\nSecure access using credential vending\n: The catalog supports multiple authorization mechanisms, letting you choose between\ncredential vending\nand end-user credentials. This means that you can access tables with modern mechanisms such as credential vending without needing direct access to the files in the underlying object store (Cloud Storage, AWS S3, Azure Blob Storage).\nAI-powered context and governance:\nThe Lakehouse runtime catalog integrates directly with\nKnowledge Catalog\nand\nCloud IAM\n, allowing you to define trusted context for your agents, and apply table-level security consistently across all compute engines.\nGet out-of-the-box search, lineage, and insights for Iceberg tables in the catalog.\nAtomic commits and concurrency control, high availability and scalability:\nBacked by Google’s planet-scale infrastructure and Spanner, you get the high availability, concurrency and scale you need for your metadata to scale with your data. Support for Cloud Storage dual-region and multi-region buckets enables failover use cases. It also provides reduced TCO due to serverless and no-ops environments, and scalability for any workload size.\nWhat powers the Lakehouse runtime catalog?\nThe Lakehouse runtime catalog is a highly available, concurrent and scalable catalog with strong consistency guarantees because it is built on top of\nSpanner\n. Unlike traditional scale-up relational databases that hit vertical single-node ceilings, Spanner combines full relational SQL semantics and multi-table ACID transactions with the horizontal scale-out elasticity for both reads and writes of a NoSQL system.\nSpanner makes the Lakehouse runtime catalog highly available through Spanner’s\nregional configurations\nwith up to 99.99% availability. Spanner also delivers out-of-the-box scalability for  Lakehouse runtime catalog: As a horizontally scalable database, Spanner does not require manual sharding and scales compute and storage independently and transparently. Spanner dynamically monitors data volume and query load, splitting and redistributing data ranges across nodes. Compute nodes scale dynamically based on CPU utilization and storage thresholds. Spanner automatically detects split-level overload and moves heavy splits away from overloaded nodes. Spanner also lets Lakehouse runtime catalog users eliminate the\ntraditional trade-offs\nbetween relational consistency and distributed scalability, delivering Lakehouse runtime catalog’s industry-leading\nconsistency guarantees\n. Lakehouse transactions are serializable — the order of transactions within the database is the same as the order in which clients observe the transactions to have been committed.\nThis foundation allows Lakehouse users to operate at agent-scale.\nThen, to further power agentic use cases, the Lakehouse runtime catalog integrates directly with Knowledge Catalog to easily discover lakehouse Iceberg tables and provide trusted context to agents. Knowledge Catalog leverages an efficient combination of\nfull-text search\nand native\nvector search\nprovided by Spanner; this approach enables better recall for search retrieval, pairing lexical keyword searches with semantic embeddings in a single query. Because both index types are built on the identical base dataset, they update with strict, transactional ACID consistency alongside base table DML operations. This removes operational overhead such as managing sync pipelines, and external-vector and full-text search systems. In short, the Lakehouse runtime catalog provides faster time-to-market for your agentic use cases.\nCombine analytical and operational workloads\nWith Google Cloud’s borderless Lakehouse based on Apache Iceberg, you can combine your analytical data with your operational workloads. Use cases span combining data assets from your Lakehouse with OLTP data (from Spanner) for analytics, to low-latency serving applications where your Lakehouse assets are accessible in an operational database such as Spanner, to conversational analytics in first-party and third-party agents.\nBelow, in an example, you can see the Lakehouse runtime catalog with Spanner in action. Here, we combine analytical data for taxi trips in Manhattan (backed by Apache Iceberg) with operational data for taxi zones in Spanner to find the most congested traffic routes. The example also shows that you can also use a Conversational Analytics Agent to access the same data and get second-order insights.\nFind out most congested traffic routes in Manhattan\nModernize to the borderless Lakehouse\nModernizing to Google Cloud’s\nLakehouse\nminimizes data silos across analytics engines and agents, unifies multi-engine governance, provides trusted context to your agents and slashes operational TCO. Leveraging the Spanner-based Lakehouse\nruntime catalog\nhelps prepare your modern cloud environments to operate at agent-scale. To learn more and get started with a free trial, visit the\nLakehouse\nweb\npage and learn more about Spanner\nhere\n.\nPosted in\nData Analytics\nDatabases\nRelated articles\nData Analytics\nAccelerating analytics: PayPal’s journey with Managed Service for Apache Spark\nBy Vinod Ganesan • 3-minute read\nAI & Machine Learning\nEmpower your agents with the Google Cloud CLI remote MCP server\nBy Prosper Nwankpa • 6-minute read\nData Analytics\nIntroducing Ask, a new Google Earth Engine feature to accelerate geospatial coding\nBy Joel Conkling • 4-minute read\nData Analytics\nMaximizing Apache Spark availability: Mitigating compute stockouts with flexible VMs and other best practices\nBy Sravani Bobbala • 8-minute read",
        "metadata": {
          "referrer": "origin",
          "viewport": "initial-scale=1, width=device-width",
          "track-metadata-page_hosting_platform": "blog_boq",
          "mobile-web-app-capable": "yes",
          "apple-mobile-web-app-capable": "yes",
          "application-name": "Google Cloud Blog",
          "apple-mobile-web-app-title": "Google Cloud Blog",
          "apple-mobile-web-app-status-bar-style": "black",
          "msapplication-tap-highlight": "no",
          "description": "Learn how the Lakehouse runtime catalog built on the Apache Iceberg REST catalog specification and powered by Spanner powers agentic workloads.",
          "robots": "max-image-preview:large",
          "og:title": "Lakehouse runtime catalog powered by Spanner | Google Cloud Blog",
          "og:type": "website",
          "og:url": "https://cloud.google.com/blog/products/data-analytics/lakehouse-runtime-catalog-powered-by-spanner",
          "og:image": "https://storage.googleapis.com/gweb-cloudblog-publish/images/09_-_Data_Analytics_tFH57V6.max-2600x2600.jpg",
          "og:description": "Learn how the Lakehouse runtime catalog built on the Apache Iceberg REST catalog specification and powered by Spanner powers agentic workloads.",
          "og:site_name": "Google Cloud Blog",
          "twitter:card": "summary_large_image",
          "twitter:url": "https://cloud.google.com/blog/products/data-analytics/lakehouse-runtime-catalog-powered-by-spanner",
          "twitter:title": "Lakehouse runtime catalog powered by Spanner | Google Cloud Blog",
          "twitter:description": "Learn how the Lakehouse runtime catalog built on the Apache Iceberg REST catalog specification and powered by Spanner powers agentic workloads.",
          "twitter:image": "https://storage.googleapis.com/gweb-cloudblog-publish/images/09_-_Data_Analytics_tFH57V6.max-2600x2600.jpg",
          "twitter:site": "@googlecloud",
          "track-metadata-page_post_title": "Lakehouse runtime catalog powered by Spanner",
          "track-metadata-page_post_labels": "Data Analytics",
          "track-metadata-page_first_published": "2026-10-07 07:10:00",
          "published_time": "2026-10-07T07:00:06+0800",
          "track-metadata-page_last_published": "2026-10-07 07:10:00",
          "track-metadata-page_post_author": "Vinod Ramachandran",
          "track-metadata-page_post_author_role": "Product Manager",
          "authors": "Vinod Ramachandran,Mina Mikhail",
          "page": "59672",
          "locale": "en",
          "content_type": "blog.articlepage",
          "tags": "Data Analytics,Databases",
          "read_duration": "8"
        },
        "extraction": "article/main",
        "verified": false
      }
    },
    {
      "title": "Call for proposals: sharing lessons on adoption and scale",
      "url": "https://openid.net/call-for-proposals-sharing-lessons-on-adoption-and-scale",
      "source": "OpenID Foundation",
      "published": "2026-10-06T20:09:04+08:00",
      "excerpt": "Moving from implementation to widespread adoption and scale is a significant challenge faced by digital identity and credential ecosystems around the world. They need to build trust and serve issuers, relying parties, and credential holders. They must also enable interoperability across sectors and borders. Having seen this challenge firsthand, the OpenID Foundation is often called […] The post Call for proposals: sharing lessons on adoption and scale first appeared on OpenID Foundation .",
      "topics": [
        "identity"
      ],
      "is_new": false,
      "first_seen": "2026-10-07T17:38:33.161622+08:00",
      "article": {
        "ok": true,
        "final_url": "https://openid.net/call-for-proposals-sharing-lessons-on-adoption-and-scale/",
        "text": "Call for proposals: sharing lessons on adoption and scale\nPublished October 6, 2026\nMoving from implementation to widespread adoption and scale is a significant challenge faced by digital identity and credential ecosystems around the world. They need to build trust and serve issuers, relying parties, and credential holders. They must also enable interoperability across sectors and borders.\nHaving seen this challenge firsthand, the OpenID Foundation is often called on to advise ecosystems as they grow. The Foundation recognizes the value of the lessons being learned along the way, and is keen to make them available to others.\nThe\nOpenID Well-Known Conference\n, taking place February 2–4 2027 in London, aims to do just that.\nThe conference will bring together ecosystem leaders, practitioners, and standards experts in order to learn from each other.\nTo facilitate this, the OpenID Foundation is calling for proposals with a strong focus on addressing how standards and technology can help digital identity and credential ecosystems drive adoption and achieve scale.\nElizabeth Garber, the OpenID Foundation’s Strategy and Marketing Director, reiterates this: “Every ecosystem that works toward scale learns lessons that others can use. This conference is about sharing them. We want to hear practical, honest accounts of what worked, what did not, and what people would do differently. Organizations take different approaches, and there is value in learning from all of them, whether a program has reached scale or is still working toward it.”\nThe guidance below is intended to help speakers shape their submissions.\nProposals that help others learn\nEach proposal should consider one question: how does this story contribute to adoption, scalability, or both? On scale, proposals might explain how trust was scaled across the ecosystem, and what barriers or challenges arose along the way. On adoption, they might set out how adoption was achieved, and what is being done to increase or accelerate it.\nStrong proposals also:\nOffer lessons another ecosystem or jurisdiction could apply.\nExplain how an ecosystem got to where it is, not only what it built.\nShare what did not work, as well as what did.\nConsider relying parties and credential holders, not only issuers.\nFocus on experience and insight, rather than products or services.\nLink AI and identity topics clearly to adoption or scale.\nHow to submit\nThe proposals can be\nsubmitted here\n.\nTickets are already available and can be booked through Eventbrite\nhere\n.\nMembers interested in sponsorship can review the\nSponsor Prospectus\n.\nAbout the OpenID Foundation\nThe OpenID Foundation (OIDF) is a global open standards body committed to building trusted identity ecosystems. Our mission is to lead the global community in identity standards that are secure, interoperable, and privacy respecting. Founded in 2007, we are a community of technical experts. The Foundation's OpenID Connect standard is now used by billions of people across millions of applications. More recently, the FAPI security profile - built on OAuth 2.0 - has become the standard of choice for interoperable Open Banking and Open Data implementations, while OpenID for Verifiable Credentials specifications are underpinning a new generation of digital wallets. Today, the OpenID Foundation's standards are the connective tissue that enable people to assert their identity and access their data at scale, the scale of the internet, enabling \"networks of networks\" to interoperate globally. Individuals, companies, governments and non-profits are encouraged to join or participate. Find out more at openid.net.\nTagged\nAdoption\nCall for Proposals\ndigital credentials\nDigital Identity\necosystems\nInteroperability\nOpenID Well-Known Conference",
        "metadata": {
          "viewport": "width=device-width, initial-scale=1",
          "google-site-verification": "xM669e_MQhVON6gTLjrj9HDvpsAim6O_tipiUTjxHVU",
          "description": "The OpenID Foundation invites proposals for the OpenID Well-Known Conference, sharing lessons on adoption and scale in digital identity ecosystems.",
          "robots": "max-image-preview:large",
          "author": "Serj Hallam",
          "generator": "Elementor 4.3.4; features: additional_custom_breakpoints; settings: css_print_method-external, google_font-enabled, font_display-swap",
          "og:locale": "en_US",
          "og:site_name": "OpenID Foundation - Helping people assert their identity wherever they choose",
          "og:type": "article",
          "og:title": "Call for proposals: sharing lessons on adoption and scale",
          "og:description": "The OpenID Foundation invites proposals for the OpenID Well-Known Conference, sharing lessons on adoption and scale in digital identity ecosystems.",
          "og:url": "https://openid.net/call-for-proposals-sharing-lessons-on-adoption-and-scale/",
          "og:image": "https://openid.net/wp-content/uploads/2022/11/df-l-oix-l-openid_rgb-300dpi.png",
          "og:image:secure_url": "https://openid.net/wp-content/uploads/2022/11/df-l-oix-l-openid_rgb-300dpi.png",
          "article:published_time": "2026-10-06T12:09:04+00:00",
          "article:modified_time": "2026-10-06T12:09:04+00:00",
          "twitter:card": "summary_large_image",
          "twitter:site": "@openid",
          "twitter:title": "Call for proposals: sharing lessons on adoption and scale",
          "twitter:description": "The OpenID Foundation invites proposals for the OpenID Well-Known Conference, sharing lessons on adoption and scale in digital identity ecosystems.",
          "twitter:creator": "@openid",
          "twitter:image": "https://openid.net/wp-content/uploads/2023/06/OG.jpg",
          "msapplication-TileImage": "https://openid.net/wp-content/uploads/2022/11/favicon_23-300x300.jpg",
          "position": "3"
        },
        "extraction": "article/main",
        "verified": false
      }
    },
    {
      "title": "Networking for AI inference model serving - GKE only and for all other backends",
      "url": "https://cloud.google.com/blog/topics/developers-practitioners/networking-for-ai-inference-model-serving-gke-only-and-for-all-other-backends",
      "source": "Google Cloud · Agent 身份",
      "published": "2026-10-06T20:00:00+08:00",
      "excerpt": "Enterprises and individual developers frequently run multiple AI inference models. The right architecture can simplify how the models are called while also providing centralized governance. In this post, we'll look at two reference architectures focused on networking AI inference model serving: one for Google Kubernetes Engine (GKE) and one all other backend types. First, we'll explore the commonalities between the reference architectures that you'll see later. Then we'll explore unique components of the architecture for GKE backends and finally, we'll go over the elements of the architecture for all backend types. The entry point You can exp",
      "topics": [
        "ai_agent"
      ],
      "is_new": false,
      "first_seen": "2026-10-07T17:38:33.161622+08:00",
      "article": {
        "ok": true,
        "final_url": "https://cloud.google.com/blog/topics/developers-practitioners/networking-for-ai-inference-model-serving-gke-only-and-for-all-other-backends",
        "text": "Developers & Practitioners\nNetworking for AI inference model serving - GKE only and for all other backends\nOctober 7, 2026\nAmmett Williams\nDeveloper Relations Engineer\nEnterprises and individual developers frequently run multiple AI inference models. The right architecture can simplify how the models are called while also providing centralized governance.\nIn this post, we'll look at two reference architectures focused on networking AI inference model serving: one for\nGoogle Kubernetes Engine (GKE)\nand one all other backend types. First, we'll explore the commonalities between the reference architectures that you'll see later. Then we'll explore unique components of the architecture for GKE backends and finally, we'll go over the elements of the architecture for all backend types.\nThe entry point\nYou can expose your model deployment behind a stable, secure, and reliable entry point that acts as the front end for inference calls. This entry point also acts as a control zone where policy, security, and logic can be enforced.\nBoth the Cloud Load balancer and the Inference Gateway provide entry point capability. These types of endpoints can terminate secure connections with TLS, integrate with API management components, extend functionally with service extensions, and capitalize on capabilities of Model Armor for added security.\nCommon services in the designs\nBoth reference designs use these services:\nPrivate Service Connect inference endpoint\n: Anchors the entry point inside your consumer Virtual Private Cloud (VPC) network. Traffic hits a private internal\nIP address\n, keeping inference calls in your private network.\nApigee API Management\n(Optional)\n: Integrates via an Apigee Extension Processor callout to handle client identity verification, rate limits, and quota enforcement before requests ever reach compute resources.\nModel Armor\n: Serves as an inline AI safety checkpoint, screening prompts and output completions against prompt injection and sensitive data leakage.\nDesign pattern serving on GKE only\nThis section focuses on a GKE-only backend design.\nTo understand the full end-to-end concept, please read the entire architecture document\nNetworking for AI inference model serving on GKE\n.\nThe design pattern is based on this diagram:\nIn addition to the common services identified in the previous section, the design for GKE uses these components:\nGKE Inference Gateway\n: Deployed as an internal Application Load Balancer (\ngke-l7-rilb\n). It acts as a specialized ingress engine that parses incoming request payloads, evaluates HTTPRoute rules, and steers queries to appropriate model-serving targets.\nInference pools\n: A logical group containing replicas of the same model. When the Gateway receives a prompt, it evaluates HTTPRoute rules to select the appropriate inference pool based on the model identifier. Pools have an initial size and can be configured to autoscale dynamically.\nModel replica sets\n: Individual model replicas (inference server instances) deployed across single-node or multi-node GPU or TPU node pools. A replica set represents a uniform group of these model replicas.\nThe traffic flow GKE example\nA client application that uses this GKE-based architecture to call a backend model would go through a flow like this:\nIngress\n: A client application in the consumer VPC issues an OpenAI-compatible API call to the local Private Service Connect endpoint, routing directly to the GKE Inference gateway using a regional internal Application Load Balancer.\nPayload inspection\n: The Gateway reads the target model parameter specified in the request body and adds it to the HTTP headers.\nControl plane validation\n: If Apigee is used, it checks client credentials and quotas. Model Armor screens the prompt for policy violations or data leakage.\nBackend selection\n: The Gateway evaluates HTTPRoute mappings to identify the target pool, matches shared prefix cache context, and routes to the lowest-load GPU or TPU replica based on real-time Prometheus data.\nEgress\n: The replica runs the inference workload. Output tokens pass through Model Armor for final response verification before streaming back over the private connection.\nDesign pattern serving on all backends\nThis section focuses on multiple backend types which can be used for inference, and it provides an overview of the architecture in the following diagram.\nTo understand the full end-to-end concept, please read the entire architecture document\nNetworking for AI inference model serving on all backends\n.\nFor architectures spanning mixed environments such as GKE, Cloud Run, Agent Platform, on-premises data centers, or external clouds, these additional components are used:\nRegional internal Application Load Balancer\n: Serves as the central Layer 7 routing proxy that manages routing logic, SSL termination, and Service Extensions callouts.\nInference Payload Processor\n(Service Extensions)\n: This is similar to body-based routing as used in the GKE Inference Gateway, but to enable the functionality on an Application Load Balancer a service extension is needed.\nA lightweight Cloud Run callout inspects the JSON body of incoming OpenAI API requests, extracts the target model identifier, and writes an X-Gateway-Model-Name header to drive URL map routing.\nNetwork Endpoint Group (NEG)\n: Delivers flexible routing to heterogeneous backends based on the injected model header.\nAll-backends traffic flow example\nA client application that uses this architecture to call a backend model would go through a flow like this:\nPrivate ingress\n: The client application targets the Private Service Connect endpoint over private IP address space. The regional internal Application Load Balancer receives the request.\nModel name extraction\n: The load balancer sends the payload to the Cloud Run body-based router callout, which inspects the JSON payload and injects the X-Gateway-Model-Name header.\nPolicy and safety enforcement\n: The request passes to Apigee for identity and quota validation, then to Model Armor to scrub sensitive data and block malicious prompts.\nNEG routing\n: The load balancer URL map inspects the model header and forwards the request to the matching backend NEG (Agent Platform, GKE, Cloud Run, Hybrid, or Internet).\nPrivate delivery\n: The target backend executes the model prompt, Model Armor screens the completion, and the result returns privately along the ingress path.\nWhat's next\nTake a deeper dive into building AI workloads on Google Cloud:\nDocument set:\nAgentic AI architecture guides\nArchitecture Center:\nMulti-agent private networking patterns in Google Cloud\nDocument:\nGemini Enterprise Agent Platform networking access overview\nWant to ask a question, find out more, or share a thought? Please connect with me on\nLinkedin\n.\nPosted in\nDevelopers & Practitioners\nNetworking\nRelated articles\nDevelopers & Practitioners\nAnnouncing MCP Toolbox Java SDK v1.0: Agentic data access for the enterprise\nBy Abirami Sukumaran • 8-minute read\nContainers & Kubernetes\nGKE CPU startup boost: Accelerate app starts without over-provisioning\nBy Abdel Sghiouar • 6-minute read\nDevelopers & Practitioners\nDemocratizing Managed Lustre with lower cost and frictionless development\nBy Barak Epstein  • 6-minute read\nDevelopers & Practitioners\nIntroducing the Server Side Cloud Swift SDK\nBy Karl Weinmeister • 6-minute read",
        "metadata": {
          "referrer": "origin",
          "viewport": "initial-scale=1, width=device-width",
          "track-metadata-page_hosting_platform": "blog_boq",
          "mobile-web-app-capable": "yes",
          "apple-mobile-web-app-capable": "yes",
          "application-name": "Google Cloud Blog",
          "apple-mobile-web-app-title": "Google Cloud Blog",
          "apple-mobile-web-app-status-bar-style": "black",
          "msapplication-tap-highlight": "no",
          "description": "",
          "robots": "max-image-preview:large",
          "og:title": "Networking for AI inference model serving - GKE only and for all other backends | Google Cloud Blog",
          "og:type": "website",
          "og:url": "https://cloud.google.com/blog/topics/developers-practitioners/networking-for-ai-inference-model-serving-gke-only-and-for-all-other-backends",
          "og:image": "https://storage.googleapis.com/gweb-cloudblog-publish/images/networking-ai-inference-model-serving-hero.max-2500x2500.png",
          "og:site_name": "Google Cloud Blog",
          "twitter:card": "summary_large_image",
          "twitter:url": "https://cloud.google.com/blog/topics/developers-practitioners/networking-for-ai-inference-model-serving-gke-only-and-for-all-other-backends",
          "twitter:title": "Networking for AI inference model serving - GKE only and for all other backends | Google Cloud Blog",
          "twitter:description": "",
          "twitter:image": "https://storage.googleapis.com/gweb-cloudblog-publish/images/networking-ai-inference-model-serving-hero.max-2500x2500.png",
          "twitter:site": "@googlecloud",
          "track-metadata-page_post_title": "Networking for AI inference model serving - GKE only and for all other backends",
          "track-metadata-page_post_labels": "Developers & Practitioners",
          "track-metadata-page_first_published": "2026-10-07 03:10:00",
          "published_time": "2026-10-07T03:00:03+0800",
          "track-metadata-page_last_published": "2026-10-07 03:10:00",
          "track-metadata-page_post_author": "Ammett Williams",
          "track-metadata-page_post_author_role": "Developer Relations Engineer",
          "authors": "Ammett Williams",
          "page": "59611",
          "locale": "en",
          "content_type": "blog.articlepage",
          "tags": "Developers & Practitioners,Networking",
          "read_duration": "6"
        },
        "extraction": "article/main",
        "verified": false
      }
    }
  ],
  "sources": [
    {
      "name": "FIDO Alliance",
      "url": "https://fidoalliance.org/feed/",
      "ok": true,
      "matched": 0,
      "undated_skipped": 0
    },
    {
      "name": "OpenID Foundation",
      "url": "https://openid.net/feed/",
      "ok": true,
      "matched": 1,
      "undated_skipped": 0
    },
    {
      "name": "Microsoft Security",
      "url": "https://www.microsoft.com/en-us/security/blog/feed/",
      "ok": true,
      "matched": 0,
      "undated_skipped": 0
    },
    {
      "name": "IETF Blog",
      "url": "https://www.ietf.org/blog/feed/",
      "ok": true,
      "matched": 0,
      "undated_skipped": 0
    },
    {
      "name": "Auth0 · AI Agent 身份",
      "url": "https://auth0.com/blog/rss.xml",
      "ok": true,
      "matched": 0,
      "undated_skipped": 0
    },
    {
      "name": "WorkOS · AI Agent 身份",
      "url": "https://workos.com/blog/rss.xml",
      "ok": true,
      "matched": 0,
      "undated_skipped": 0
    },
    {
      "name": "AWS Security",
      "url": "https://aws.amazon.com/blogs/security/feed/",
      "ok": true,
      "matched": 2,
      "undated_skipped": 0
    },
    {
      "name": "AWS AI · Agent 身份",
      "url": "https://aws.amazon.com/blogs/machine-learning/feed/",
      "ok": true,
      "matched": 0,
      "undated_skipped": 0
    },
    {
      "name": "Google Cloud · Agent 身份",
      "url": "https://cloudblog.withgoogle.com/rss/",
      "ok": true,
      "matched": 3,
      "undated_skipped": 0
    },
    {
      "name": "Cloudflare · Agent 身份",
      "url": "https://blog.cloudflare.com/rss/",
      "ok": true,
      "matched": 0,
      "undated_skipped": 0
    },
    {
      "name": "GitHub Security · Agent 身份",
      "url": "https://github.blog/security/feed/",
      "ok": true,
      "matched": 0,
      "undated_skipped": 0
    },
    {
      "name": "GitHub Changelog · Agent 身份",
      "url": "https://github.blog/changelog/feed/",
      "ok": true,
      "matched": 0,
      "undated_skipped": 0
    },
    {
      "name": "SPIFFE / SPIRE",
      "url": "https://spiffe.io/blog/index.xml",
      "ok": true,
      "matched": 0,
      "undated_skipped": 0
    }
  ],
  "web_sources_pending": [
    {
      "name": "Auth0 AI 专栏",
      "url": "https://auth0.com/blog/ai/",
      "focus": "ai_agent",
      "reason": "补查总 RSS 未覆盖的专栏文章"
    },
    {
      "name": "Descope Blog",
      "url": "https://www.descope.com/blog",
      "focus": "ai_agent",
      "reason": "未确认可用 RSS，每日网页核验 Agentic Identity Hub、Agent SSO 和 MCP 认证动态"
    },
    {
      "name": "OpenID AIIM 社区组",
      "url": "https://openid.net/cg/artificial-intelligence-identity-management-community-group/",
      "focus": "ai_agent",
      "reason": "补查 AI 身份研究、互操作活动与社区进展，必须核实发布时间"
    },
    {
      "name": "MCP 官方规范",
      "url": "https://modelcontextprotocol.io/specification/latest/basic/authorization",
      "focus": "ai_agent",
      "reason": "关注授权规范变更，静态文档不得当作新增新闻"
    },
    {
      "name": "Google Cloud Security & Identity",
      "url": "https://cloud.google.com/blog/products/identity-security",
      "focus": "ai_agent",
      "reason": "补查总 RSS 最新 20 条未覆盖的 Agent Identity、IAM 和工作负载身份文章"
    },
    {
      "name": "Microsoft Entra Blog",
      "url": "https://techcommunity.microsoft.com/blog/microsoft-entra-blog",
      "focus": "ai_agent",
      "reason": "关注 Entra Agent ID；测试的 RSS 返回 404 或空列表，网页打不开时通过官方域名检索补查并记录失败"
    },
    {
      "name": "Alibaba Cloud Agent Identity",
      "url": "https://www.alibabacloud.com/help/en/agentidentity/",
      "focus": "ai_agent",
      "reason": "关注阿里云智能体身份和凭证服务；静态文档只有核实日期、版本和实质变更后才算新增"
    },
    {
      "name": "AWS AgentCore Identity",
      "url": "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity.html",
      "focus": "ai_agent",
      "reason": "补查产品发布说明与身份功能变更，静态文档不得作为今日新闻"
    }
  ],
  "web_checks": [
    {
      "name": "Auth0 AI 专栏",
      "url": "https://auth0.com/blog/ai/",
      "focus": "ai_agent",
      "reason": "补查总 RSS 未覆盖的专栏文章",
      "page": {
        "ok": true,
        "final_url": "https://auth0.com/blog/ai/",
        "text": "Auth0 AI Articles\nLogin\nDevelopers\nDevelopers\nDeveloper Center\nCode Samples\nGuides\nIdentity Unlocked - Podcasts\nZero Index Newsletter\nDeveloper Tools\nOIDC Connect Playground\nSAML Tool\nJWT.io\nWebauthn.me\nGet Involved\nEvents\nAuth0 Research Program\nDocumentation\nDocumentation\nAuth0 Docs\nArticles\nQuickstarts\nAPIs\nSDK Libraries\nSupport Center\nCommunity\nSupport\nKnowledge Base\nExplore Auth0 Marketplace\nResources\nBlog\nLearn\nIntro to IAM (CIAM)\nProduct\nPlatform\nAuth0 for AI Agents\nAccess Management\nExtensibility\nSecurity\nUser Management\nAuthentication\nFine-Grained Authorization\nView platform\nFeatures\nUniversal Login\nSingle Sign-On\nMultifactor Authentication\nActions\nMachine to Machine\nPasswordless\nBreached Passwords\nToken Vault\nView features\nSolutions\nCustomer Identity Trends Report 2025\nIndustries\nRetail\nFinancial Services\nNonprofits & Charities\nStartups\nHealthcare\nUse Cases\nConsumer Applications\nB2B SaaS Applications\nBlog\nPricing\nSign up\nLogin\nLet's connect\nDevelopers\nDevelopers\nDeveloper Center\nCode Samples\nGuides\nIdentity Unlocked - Podcasts\nZero Index Newsletter\nDeveloper Tools\nOIDC Connect Playground\nSAML Tool\nJWT.io\nWebauthn.me\nGet Involved\nEvents\nAuth0 Research Program\nDocumentation\nDocumentation\nAuth0 Docs\nArticles\nQuickstarts\nAPIs\nSDK Libraries\nSupport Center\nCommunity\nSupport\nKnowledge Base\nExplore Auth0 Marketplace\nResources\nBLOG\nGetting Unlimited Scalability with Okta Fine-Grained Authorization\nBlog\nLearn\nIntro to IAM (CIAM)\nProduct\nPlatform\nAuth0 for AI Agents\nAccess Management\nExtensibility\nSecurity\nUser Management\nAuthentication\nFine-Grained Authorization\nView platform\nFeatures\nUniversal Login\nSingle Sign-On\nMultifactor Authentication\nActions\nMachine to Machine\nPasswordless\nBreached Passwords\nToken Vault\nView features\nTechnology Overview\nWatch a walkthrough of the Auth0 Platform\nCloud Deployments\nDeploy to the cloud, your way\nAuth0 Marketplace\nDiscover the integrations you need to solve identity\nSolutions\nIndustries\nRetail\nFinancial Services\nNonprofits & Charities\nStartups\nHealthcare\nYour goals\nEnterprise-Grade Identity at Scale\nShip AI Agents\nArchitecture Playbook\nUse Cases\nConsumer Applications\nB2B SaaS Applications\nCase Studies\nRead our customers stories\nCustomer Identity Trends Report 2025\nSecuring customer trust in the age of AI\nCIAM ROI Calculator\nEstimate the revenue impact to your customer-facing business\nAI PRODUCT INNOVATIONS\nNew tools to safely ship and scale agentic apps\nBlog\nPricing\nSign up\nLet's connect\nBlog\nExplore Topics\nAI\nDevelopers\nIdentity & Security\nBusiness\nCulture\nEngineering\nAnnouncements\nSystem\nDark mode\nLight mode\nBlog\nAI\nDevelopers\nIdentity & Security\nBusiness\nCulture\nEngineering\nAnnouncements\nSystem\nDark mode\nLight mode\nBlog\nAI\nTags\n#mcp server\n#mcp\n#ucp\n#authorization\n#ai\n#chatgpt\n#confused-deputy\n#csrf\n#ssrf\n#cursor\n#authentication\n#mfa\n#ai-agents\n#security\n#llm\n#agentic-ai\n#multi-agent\n#python\n#flask\n#auth0-cli\n#ciba\n#token vault\n#ai agent\n#documentation\n#ai agents\n#secret\n#agent-skills\n#tools\n#app development\n#software engineer\n#identity\n#token-vault\n#oauth2\n#claude-code\n#openfga\n#agent skills\n#fga\n#rag\n#google\n#openclaw\n#credentials\n#llamaindex\n#jwt\n#auth0-fga\n#auth0 mcp server\n#gemini cli\n#gemini\n#c#\n#csharp\n#dotnet\nView more\n(\n69\n)\nRecommended authors\nJuan Cruz Martinez\nJessica Temporal\nDeepu K Sasidharan\nView all authors\nLatest posts (\n10\nof\n89\nresults)\nFilter\nai\nSep 29, 2026 • 19 min read\nIntegrating Claude Code with Auth0 APIs\nManish Hatwalne\n#mcp server\n#mcp\nai\nSep 28, 2026 • 4 min read\nAuth0 for ChatGPT - Build and Manage Identity by Just Asking\nJuan Cruz Martinez\n#ai\n#chatgpt\nai\nSep 28, 2026 • 6 min read\nSecuring Agentic Commerce Using Auth0 and the Universal Commerce Protocol (UCP)\nKarim Tantawy\n,\nSamantha Murphy\n#ucp\n#authorization\n#ai\nai\nSep 22, 2026 • 10 min read\nConfused Deputy: The Old Bug That AI Agents Keep Reintroducing\nAndrea Chiarelli\n#confused-deputy\n#csrf\n#ssrf\nai\nSep 17, 2026 • 16 min read\nPreventing Destructive Actions with Step-up Authentication\nJessica Temporal\n#cursor\n#authentication\n#mfa\nai\nJul 24, 2026 • 5 min read\nAgentic Loops and Agent Graphs: Security Risks You Need to Know\nCarla Urrea Stabile\n#ai-agents\n#security\n#llm\nai\nSep 14, 2026 • 9 min read\nHow to Set Up a Flask App with Cursor and the Auth0 Plugin\nJessica Temporal\n#python\n#flask\n#cursor\nai\nJul 13, 2026 • 10 min read\nClosing the Audit Gap in Human-to-Agent Delegation\nVivek Kumar Maskara\n#ciba\n#token vault\n#ai\nai\nJun 29, 2026 • 5 min read\nAdd Auth0 Documentation to Claude Code\nJessica Temporal\n#mcp\n#documentation\n#ai\nai\nJun 26, 2026 • 10 min read\nWant AI Agents That Don't Spill Secrets? Don't Give Them Secrets\nAndrea Chiarelli\n#ai\n#llm\n#security\nLoad more\nRecommended authors\nJuan Cruz Martinez\nJessica Temporal\nDeepu K Sasidharan\nView all authors\nResources\nDocs\nDeveloper Center\nAuth0 Community\nTry for free today\nStop reading and start building.\nTry for free →\nContact sales\nDevelopers\nDeveloper Hub\nCode Samples and Guides\nBlog posts\nIdentity Unlocked - Podcasts\nZero Index Newsletter\nAgent Experience Score\nDocumentation\nArticles\nQuickstarts\nAPIs\nSDK Libraries\nChangelog\nBlog\nReports\nWebinars\nSupport Center\nCommunity\nSupport\nKnowledge Base\nAuth0 Marketplace\nCompany\nOur Customers\nCompliance - Ensuring privacy and security\nPartners\nCareers\nWe're hiring!\nAbout us\nGet Involved\nEvents\nAuth0 Research Program\nLearning\nLearn\nIntro to IAM (CIAM)\nBlog\nArchitecture Playbook\nPlatform\nAuth0 for AI Agents\nAccess Management\nExtensibility\nSecurity\nUser Management\nAuthentication\nCloud deployments\nFine-Grained Authorization\nFeatures\nUniversal Login\nSingle Sign-On\nMultifactor Authentication\nActions\nMachine to Machine\nPasswordless\nBreached Passwords\nToken Vault\n©\n2026\nOkta, Inc. All Rights Reserved.\nStatus\n•\nLegal\n•\nPrivacy\n•\nTerms\n•\nYour Privacy Choices\nStatus\n•\nLegal\n•\nPrivacy\n•\nTerms\n•\nYour Privacy Choices\n©\n2026\nOkta, Inc. All Rights Reserved.",
        "metadata": {
          "viewport": "width=device-width, initial-scale=1.0, maximum-scale=5.0",
          "description": "",
          "fb:app_id": "534074790006350",
          "og:type": "website",
          "og:title": "AI",
          "og:site_name": "Auth0 - Blog",
          "og:description": "",
          "og:image": "https://cdn.auth0.com/blog/illustrations/auth0.png",
          "og:url": "https://auth0.com/blog/ai/",
          "twitter:site": "@auth0",
          "twitter:creator": "@auth0",
          "twitter:title": "AI",
          "twitter:description": "",
          "twitter:url": "https://auth0.com/blog/ai/",
          "twitter:card": "summary",
          "twitter:image": "https://cdn.auth0.com/blog/illustrations/auth0.png",
          "twitter:image:height": "512",
          "twitter:image:width": "1024",
          "HandheldFriendly": "True",
          "MobileOptimized": "320",
          "next-head-count": "30"
        },
        "extraction": "visible-page",
        "verified": false
      }
    },
    {
      "name": "Descope Blog",
      "url": "https://www.descope.com/blog",
      "focus": "ai_agent",
      "reason": "未确认可用 RSS，每日网页核验 Agentic Identity Hub、Agent SSO 和 MCP 认证动态",
      "page": {
        "ok": true,
        "final_url": "https://www.descope.com/blog",
        "text": "Introducing Descope Family Accounts: Relational Identity for Consumer Apps.\nLearn more >\nLog In\nUser Circle\nProduct\nUse Cases\nDevelopers\nCustomers\nResources\nCompany\nPricing\nSign up\nArrow Right\nBook a demo\nArrow Right\nDescope Blog\nTopics\nTopics\nAll Topics\nAuth Thoughts\nCompany Updates\nDevelopers\nConnectors\nLife @ Descope\nIdentity and auth news.\nStraight to your inbox.\nSubscribe\nFollow Us\nX\nInstagram\nLinkedIn\nBluesky Social\nDescope Blog\nCompany Updates\n|\nSeptember 1, 2026\nSSO For Your Agents: Cross-App Access Support in Agentic Identity Hub\nRead More\nArrow Right\nPopular articles\nDescope Gets Honorable Mention in 2025 Gartner® Magic Quadrant™ for Access Management\nArrow Right\nIntroducing Descope Agentic Identity Hub 2.0\nArrow Right\nA Primer on B2B Authentication With Descope\nArrow Right\n4 Ways to Improve Conversion With User Journey A/B Testing\nArrow Right\nCustomer Spotlight: Why We Moved From Ory Kratos to Descope\nArrow Right\nMCP Server Security Best Practices to Prevent Risk\nArrow Right\nAll Topics\nAuth Thoughts\n|\nOct 6, 2026\nMCP Server Security Best Practices to Prevent Risk\nRead more\nDevelopers\n|\nOct 1, 2026\nFree JWT Decoder: How to Decode and Verify JSON Web Tokens\nRead more\nAuth Thoughts\n|\nSep 30, 2026\nCustomer and Agentic Identity Tips for HealthTech Apps\nRead more\nCompany Updates\n|\nSep 30, 2026\nIntroducing Descope Family Accounts: Relational Identity for Consumer Apps\nRead more\nAuth Thoughts\n|\nSep 21, 2026\nDescope vs Frontegg: Comparison and Use Cases\nRead more\nCompany Updates\n|\nSep 21, 2026\nDescope Data Residency Is Now Available in Seven Regions\nRead more\nDescope - Go to homepage\nChat with Sales\nAnonymously - no Slack account required\nLeave a Descope review\nProduct\nPlatform Overview\nDescope Flows\nEnterprise Readiness Suite\nAgentic Identity Hub\nIntegrations\nDescope vs Auth0\nDescope vs Ping Identity\nDescope vs Okta CIS\nDescope vs Amazon Cognito\nDescope vs Keycloak\nDescope vs Stytch\nDescope vs WorkOS\nDescope vs Frontegg\nApp Use Cases\nPasswordless\nIdentity Federation\nATO Prevention\nIdentity Orchestration\nAuthentication Methods\nSocial Logins\nPasskeys\nMFA\nBiometrics / WebAuthn\nMagic Links\nSSO\nOpenID Connect\nnOTP\nOne-Time Passwords\nAuthenticator Apps\nPasswords\nDevelopers\nDocs\nTutorials\nCommunity\nOpen Source\nResources\nLearning Center\nBlog\nCompany\nOur Story\nCareers\nPartners\nNewsroom\nSecurity & Compliance\nContact Us\nLegal\nPrivacy Policy\nTerms of Use\nCopyright © Descope Inc. All rights reserved.\nAll systems operational\nGithub Icon Grey\nLinkedin Icon Grey\nX Grey Icon\nInstagram Grey Logo\nSlack Icon\nYouTube Icon\nBluesky Social\nDescope - Go to homepage\nChat with Sales\nAnonymously - no Slack account required\nProduct\nApp Use Cases\nAuthentication Methods\nDevelopers\nResources\nCompany\nLegal\nLeave a Descope review\nGithub Icon Grey\nLinkedin Icon Grey\nX Grey Icon\nInstagram Grey Logo\nSlack Icon\nYouTube Icon\nBluesky Social\nAll systems operational\nCopyright © Descope Inc. All rights reserved.",
        "metadata": {
          "viewport": "width=device-width, shrink-to-fit=no, initial-scale=1, maximum-scale=5",
          "next-size-adjust": "",
          "csp-nonce": "mkXy4zJ9U4oqAYyAiZPtE4TRuLoUFyk3KgGVgQtr+EM=",
          "description": "Welcome to the Descope Blog! We share thoughts on authentication and identity, chats with developers, open-source spotlights, and security news. Subscribe for more updates.",
          "keywords": "blog,authentication,developers,passwordless,user management,security,fraud prevention",
          "robots": "index, follow, nocache, max-image-preview:large",
          "og:title": "Descope Blog",
          "og:description": "Welcome to the Descope Blog! We share thoughts on authentication and identity, chats with developers, open-source spotlights, and security news. Subscribe for more updates.",
          "og:url": "https://www.descope.com/blog",
          "og:site_name": "Descope",
          "og:locale": "en_US",
          "og:image": "https://images.ctfassets.net/xqb1f63q68s1/40ukpxpIbwjSl5FTn5HCB9/1dcc31257725f93b349665a8f7cb5ea7/Home_page_SEO___others.png",
          "og:image:width": "1280",
          "og:image:height": "720",
          "og:image:alt": "Descope",
          "og:type": "website",
          "twitter:card": "summary_large_image",
          "twitter:title": "Descope Blog",
          "twitter:description": "Welcome to the Descope Blog! We share thoughts on authentication and identity, chats with developers, open-source spotlights, and security news. Subscribe for more updates.",
          "twitter:image": "https://images.ctfassets.net/xqb1f63q68s1/40ukpxpIbwjSl5FTn5HCB9/1dcc31257725f93b349665a8f7cb5ea7/Home_page_SEO___others.png"
        },
        "extraction": "article/main",
        "verified": false
      }
    },
    {
      "name": "OpenID AIIM 社区组",
      "url": "https://openid.net/cg/artificial-intelligence-identity-management-community-group/",
      "focus": "ai_agent",
      "reason": "补查 AI 身份研究、互操作活动与社区进展，必须核实发布时间",
      "page": {
        "ok": true,
        "final_url": "https://openid.net/cg/artificial-intelligence-identity-management-community-group/",
        "text": "Artificial Intelligence Identity Management Community Group\nThis CG provides a safe space to assess use cases, modularization (role, scope, outcomes), existing and emerging AI architectures, progress CG and whitepaper recommendations, develop liaisons, and mature other AI community partners as appropriate.\nAI Identity Management\nOVERVIEW\nAI Identity Management\nREPOSITORY\nAI Identity Management\nPARTICIPATION AGREEMENTS\nWhat is the Artificial Intelligence Identity Management Community Group\nAI is disrupting many dimensions of the internet, digital transactions and the human/digital interface, from social interactions and commerce, to accessing news and entertainment, financial services, business to business transactions and more. However, amidst this AI revolution, a critical issue persists: the silos between the AI and Identity communities could lead AI platforms to underutilizing known identity standards, emerging gaps in standards may not be progressed at the optimal pace, and known problems in security, privacy and interoperability may be repeated leading to unnecessary pitfalls. Collaboration between the AI and standards experts could deliver speed to market and substantially derisk end products and services.\nKnown gaps in standards around delegated authority are already being remediated in the eKYC and IDA WG (e.g. the authority specification), but other gaps in standards are not yet well characterized, such as how to assert the identity of the LLM and/or agent to the external servers it communicates with; or how to define the contents of a token that is moving between 2 or more AI agents, (and not from consumer to IdP). Similarly, we see gaps emerging in the discovery of AI agents, gaps in governance models, and other issues that could be addressed at pace through OIDF, other SDO liaison partners (e.g. IETF), and defacto standards partners like MCP.\nThe OIDF board commissioned in April 2025 a paper on the intersection of Agentic AI and Identity that will yield consensus of an initial landscape assessment and recommendations to remediate the issues (within OIDF and beyond). This CG will serve as a safe space to assess use cases, modularization (role, scope, outcomes), existing and emerging AI architectures, progress CG and whitepaper recommendations, develop liaisons, and mature other AI community partners as appropriate.\nDeliverables & Organizing Principles\nThe proposed AI CG will focus on the following deliverables:\nOffer a safe space to review and mature consensus on the use cases, architectures and deployment models\nIdentify areas in the use cases that are not addressed by standards, and what needs to be solved.\nDevelop and document the Agentic AI champion use cases, whether for advancement within or outside of OIDF (eg by trusted partners, SDO liaisons, or defacto standards as appropriate). Use cases that are deprioritised may be deferred, or deferred for later work\nDetermine area(s) that require OIDF and identity community focus to support outcomes (including but not limited to privacy, security, operations, scale, risk management and compliance)\nMonitor the state of government AI regulations, where they exist, to modify CG approach and priorities as appropriate\nConsensus on terminology so that CG participants and wider AI/Identity experts are referring to the same terms\nEngage key stakeholders (e.g. vendors, AI agent vendors, digital platforms, identity vendors) in conversations tightly scoped by the Co-Chairs to allow for concrete progress on the CG’s deliverables and wider roadmap (noting time constraints to influence rapidly developing and scaling AI implementations)\nInform the OpenID Foundation whitepaper, and as appropriate, progress the recommendations from the AI whitepaper after publication\nThe following are out of scope for the proposed AI CG:\nDevelopment of any global standards protocols related to AI Agents & Identity. Any such protocol work will be deferred to an OIDF or liaison working group.\nThe community group will operate under the following Organizing Principles:\nRespect: OIDF Code of Conduct will apply\nEmpowerment through Consent: We seek to empower individuals to enable informed decision-making regarding the management of agents. The AI CG will advocate for consent-driven use cases which protect the privacy and security of individuals.\nInteroperability and Accessibility: The CG’s work must promote interoperability among digital platforms to facilitate seamless data management and accessibility across diverse ecosystems, ensuring inclusivity, efficiency, and usability for individuals.\nThe AI CG will operate in English. The work will progress via mailing list and telephone/internet conference calls combined with face-to-face meetings, where possible.\nNews, Videos, Events & Presentations\nThe below is a list of the press and media coverage the AIIM CG’s work has received:\nVideos\nDecember 2025\n–\nIdentity at the Center Podcast: #390 – Identity Management for Agentic AI with Tobin South\nOctober 2025\n– The OpenID Foundation’s ‘Well-known’ Podcast – When the Client is a Mind:\nPress Coverage\n2025\n19th November 2025 –\nitnews Asia –\nWhen AI agents act, who is responsible?\n13th October 2025 –\nPaypers –\nOpenID Foundation warns of security flaws in AI agent identity\n9th October 2025 –\nIdentity Week\n–\nOpenID Foundation whitepaper exposes critical AI agent security gaps\n8th October 2025 –\nSecurity Boulevard –\nZero Trust for AI Agents: Implementing Dynamic Authorization in an Autonomous World\n7th October 2025 –\nDigit News –\nNew Whitepaper Reveals Urgent Agentic AI Security Risks\n7th October 2025 –\nSecurity Boulevard\n–\nBeyond Chatbots: Why Agent Security Is the Industry’s Next Major Challenge\n7th October 2025\n– BiometricUpdate.com –\nWith the US all-in on AI, buzz on AI agents gets louder and need for trust increases\n3rd October 2025-\nSourceSecurity.com –\nOpenID Foundation AI Whitepaper on identity management\nCommunity Group Chairs\nAtul Tulshibagwale (\nCrowdStrike\n)\nJeff Lombardo (\nAWS\n)\nParticipation\nJoin the\nmailing list\n.\nParticipants need to\nsign a Participation Agreement\nMeeting Schedule\nAIIM CG meets very other Thursday at 9am PT\nJoin Meeting\nThe AIIM CG subgroups meet every other week on Thursday’s at 9am PT (when the CG call is 4pm PT on that particular Thursday):\nTaxonomy\nUse-cases\nThreat Modelling\nPlease click on the above link to join the Zoom meeting for the specific sub-group meeting you wish to attend.\nView Calendar",
        "metadata": {
          "viewport": "width=device-width, initial-scale=1",
          "google-site-verification": "xM669e_MQhVON6gTLjrj9HDvpsAim6O_tipiUTjxHVU",
          "description": "Artificial Intelligence Identity Management Community Group This CG provides a safe space to assess use cases, modularization (role, scope, outcomes), existing and emerging AI architectures, progress CG and whitepaper recommendations, develop liaisons, and mature other AI community partners as appropriate. AI Identity ManagementOVERVIEWAI Identity ManagementREPOSITORYAI Identity ManagementPARTICIPATION AGREEMENTS What is the Artificial Intelligence Identity Management Community",
          "robots": "max-image-preview:large",
          "generator": "Elementor 4.3.4; features: additional_custom_breakpoints; settings: css_print_method-external, google_font-enabled, font_display-swap",
          "og:locale": "en_US",
          "og:site_name": "OpenID Foundation - Helping people assert their identity wherever they choose",
          "og:type": "article",
          "og:title": "Artificial Intelligence Identity Management Community Group - OpenID Foundation",
          "og:description": "Artificial Intelligence Identity Management Community Group This CG provides a safe space to assess use cases, modularization (role, scope, outcomes), existing and emerging AI architectures, progress CG and whitepaper recommendations, develop liaisons, and mature other AI community partners as appropriate. AI Identity ManagementOVERVIEWAI Identity ManagementREPOSITORYAI Identity ManagementPARTICIPATION AGREEMENTS What is the Artificial Intelligence Identity Management Community",
          "og:url": "https://openid.net/cg/artificial-intelligence-identity-management-community-group/",
          "og:image": "https://openid.net/wp-content/uploads/2022/11/dots-papers.png",
          "og:image:secure_url": "https://openid.net/wp-content/uploads/2022/11/dots-papers.png",
          "og:image:width": "8051",
          "og:image:height": "5114",
          "article:published_time": "2025-06-20T17:22:17+00:00",
          "article:modified_time": "2026-04-28T18:24:33+00:00",
          "twitter:card": "summary_large_image",
          "twitter:site": "@openid",
          "twitter:title": "Artificial Intelligence Identity Management Community Group - OpenID Foundation",
          "twitter:description": "Artificial Intelligence Identity Management Community Group This CG provides a safe space to assess use cases, modularization (role, scope, outcomes), existing and emerging AI architectures, progress CG and whitepaper recommendations, develop liaisons, and mature other AI community partners as appropriate. AI Identity ManagementOVERVIEWAI Identity ManagementREPOSITORYAI Identity ManagementPARTICIPATION AGREEMENTS What is the Artificial Intelligence Identity Management Community",
          "twitter:creator": "@openid",
          "twitter:image": "https://openid.net/wp-content/uploads/2023/06/OG.jpg",
          "msapplication-TileImage": "https://openid.net/wp-content/uploads/2022/11/favicon_23-300x300.jpg",
          "position": "3"
        },
        "extraction": "article/main",
        "verified": false
      }
    },
    {
      "name": "MCP 官方规范",
      "url": "https://modelcontextprotocol.io/specification/latest/basic/authorization",
      "focus": "ai_agent",
      "reason": "关注授权规范变更，静态文档不得当作新增新闻",
      "page": {
        "ok": true,
        "final_url": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization",
        "text": "On this page\nIntroduction\nPurpose and Scope\nProtocol Requirements\nStandards Compliance\nRoles\nOverview\nAuthorization Server Discovery\nClient Registration\nScope Selection Strategy\nAuthorization Flow Steps\nAuthorization Response Validation\nResource Parameter Implementation\nCanonical Server URI\nAccess Token Usage\nToken Requirements\nToken Handling\nRefresh Tokens\nError Handling\nScope Challenge Handling\nRuntime Insufficient Scope Errors\nStep-Up Authorization Flow\nSecurity Considerations\nMCP Authorization Extensions\nAuthorization\nAuthorization\nCopy page\nCopy page\nCopy page\nCopy page\n​\nIntroduction\n​\nPurpose and Scope\nThe Model Context Protocol provides authorization capabilities at the transport level,\nenabling MCP clients to make requests to restricted MCP servers on behalf of resource\nowners. This specification defines the authorization flow for HTTP-based transports.\n​\nProtocol Requirements\nAuthorization is\nOPTIONAL\nfor MCP implementations. When supported:\nImplementations using an HTTP-based transport\nSHOULD\nconform to this specification.\nImplementations using an STDIO transport\nSHOULD NOT\nfollow this specification, and\ninstead retrieve credentials from the environment.\nImplementations using alternative transports\nMUST\nfollow established security best\npractices for their protocol.\n​\nStandards Compliance\nThis authorization mechanism is based on established specifications listed below, but\nimplements a selected subset of their features to ensure security and interoperability\nwhile maintaining simplicity:\nOAuth 2.1 IETF DRAFT (\ndraft-ietf-oauth-v2-1-13\n)\nOAuth 2.0 Bearer Token Usage\n(\nRFC6750\n)\nOAuth 2.0 Authorization Server Metadata\n(\nRFC8414\n)\nOAuth 2.0 Dynamic Client Registration Protocol\n(\nRFC7591\n)\nResource Indicators for OAuth 2.0\n(\nRFC8707\n)\nOAuth 2.0 Protected Resource Metadata (\nRFC9728\n)\nOAuth 2.0 Authorization Server Issuer Identification (\nRFC9207\n)\nOAuth Client ID Metadata Documents (\ndraft-ietf-oauth-client-id-metadata-document-00\n)\nOpenID Connect Discovery 1.0\nOpenID Connect Dynamic Client Registration 1.0 (\nOpenID Connect Registration\n)\n​\nRoles\nA protected\nMCP server\nacts as an\nOAuth 2.1 resource server\n,\ncapable of accepting and responding to protected resource requests using access tokens.\nAn\nMCP client\nacts as an\nOAuth 2.1 client\n,\nmaking protected resource requests on behalf of a resource owner.\nThe\nauthorization server\nis responsible for interacting with the user (if necessary) and issuing access tokens for use at the MCP server.\nThe implementation details of the authorization server are beyond the scope of this specification. It may be hosted with the\nresource server or a separate entity.\nAuthorization Server Discovery\nspecifies how an MCP server indicates the location of its corresponding authorization server to a client.\n​\nOverview\nAuthorization servers\nMUST\nimplement OAuth 2.1 with appropriate security\nmeasures for both confidential and public clients.\nAuthorization servers and MCP clients\nSHOULD\nsupport\nOAuth Client ID Metadata Documents\n(\ndraft-ietf-oauth-client-id-metadata-document-00\n).\nAuthorization servers and MCP clients\nMAY\nsupport the OAuth 2.0 Dynamic Client Registration\nProtocol (\nRFC7591\n). Note that\nDynamic Client Registration\nis deprecated and retained for backwards compatibility with authorization servers that do not support Client ID Metadata Documents.\nMCP servers\nMUST\nimplement OAuth 2.0 Protected Resource Metadata (\nRFC9728\n).\nMCP clients\nMUST\nuse OAuth 2.0 Protected Resource Metadata for\nauthorization server discovery\n.\nMCP authorization servers\nMUST\nprovide at least one of the following discovery mechanisms:\nOAuth 2.0 Authorization Server Metadata (\nRFC8414\n)\nOpenID Connect Discovery 1.0\nMCP clients\nMUST\nsupport both\ndiscovery mechanisms\nto obtain the information required to interact with the authorization server.\n​\nAuthorization Server Discovery\nMCP servers advertise their associated authorization servers through OAuth 2.0 Protected\nResource Metadata, and MCP clients determine authorization server endpoints and supported\ncapabilities through authorization server metadata discovery. Implementations\nMUST\nfollow the normative discovery requirements defined in\nAuthorization Server Discovery\n.\n​\nClient Registration\nBefore initiating the authorization flow, MCP clients\nMUST\nobtain a client ID through\none of three registration mechanisms: Client ID Metadata Documents, pre-registration, or\nDynamic Client Registration, following the requirements and selection priority defined in\nClient Registration\n.\n​\nScope Selection Strategy\nMCP servers\nSHOULD\ninclude a\nscope\nparameter in the\nWWW-Authenticate\nheader as defined in\nRFC 6750 Section 3\nto indicate the scopes required for accessing the resource. This provides clients with immediate\nguidance on the appropriate scopes to request during authorization,\nfollowing the principle of least privilege and preventing clients from requesting excessive permissions.\nThe scopes included in the\nWWW-Authenticate\nchallenge\nMAY\nmatch\nscopes_supported\n, be a subset\nor superset of it, or an alternative collection that is neither a strict subset nor\nsuperset. Clients\nMUST NOT\nassume any particular set relationship between the challenged\nscope set and\nscopes_supported\n. Clients\nMUST\ntreat the scopes provided in the\nchallenge as authoritative for the current operation. These scopes are required to\nsatisfy the current request. When re-authorizing, clients\nSHOULD\ninclude these scopes\nalongside any previously granted scopes to avoid losing permissions needed for other operations\n(see\nStep-Up Authorization Flow\n). Servers\nSHOULD\nstrive for\nconsistency in how they construct scope sets but they are not required to surface every dynamically\nissued scope through\nscopes_supported\n.\nExample 401 response with scope guidance:\nHTTP\n/\n1.1\n401\nUnauthorized\nWWW-Authenticate\n:\nBearer resource_metadata=\"https://mcp.example.com/.well-known/oauth-protected-resource\",\nscope=\"files:read\"\nWhen implementing authorization flows, MCP clients\nSHOULD\nfollow the principle of least privilege by requesting\nonly the scopes necessary for their intended operations. During the initial authorization handshake, MCP clients\nSHOULD\nfollow this priority order for scope selection:\nUse\nscope\nparameter\nfrom the initial\nWWW-Authenticate\nheader in the 401 response, if provided\nIf\nscope\nis not available\n, use all scopes defined in\nscopes_supported\nfrom the Protected Resource Metadata document, omitting the\nscope\nparameter if\nscopes_supported\nis undefined.\nThe\nscopes_supported\nfield is intended to represent the minimal set of scopes necessary\nfor basic functionality (see\nScope Minimization\n),\nwith additional scopes requested incrementally through the step-up authorization flow steps\ndescribed in the\nScope Challenge Handling\nsection.\n​\nAuthorization Flow Steps\nThe registration step shown in the flow uses one of the mechanisms defined in\nClient Registration\n.\nThe complete Authorization flow proceeds as follows:\n​\nAuthorization Response Validation\nBefore redirecting the user-agent, the client\nMUST\nrecord the\nissuer\nvalue from the selected authorization server’s validated metadata document (see\nAuthorization Server Metadata Discovery\n) and associate it with the same per-request record used to store the PKCE code verifier (and the\nstate\nvalue, if used). The validation in this section depends on that recorded value being authentic; it provides no protection if the expected issuer was obtained from an unvalidated source.\nMCP authorization servers\nSHOULD\ninclude the\niss\nparameter in authorization responses, including error responses, as defined in\nRFC9207 Section 2\n. Authorization servers that include the\niss\nparameter\nMUST\nadvertise this by setting\nauthorization_response_iss_parameter_supported\nto\ntrue\nin their metadata (\nRFC9207 Section 2.3\n).\nOn receiving the authorization response, MCP clients\nMUST\napply the validation in\nRFC9207 Section 2.4\nbefore transmitting the authorization code to any token endpoint:\nauthorization_response_iss_parameter_supported\niss\nin response\nClient action\ntrue\npresent\nCompare to the recorded issuer using simple string comparison (\nRFC3986 Section 6.2.1\n)\ntrue\nabsent\nReject the response\nfalse\nor absent\npresent\nCompare to the recorded issuer using simple string comparison (\nRFC3986 Section 6.2.1\n)\nfalse\nor absent\nabsent\nProceed\nThe third row applies the local-policy provision in\nRFC9207 Section 2.4\n: this specification compares a present\niss\nagainst the recorded issuer regardless of metadata advertisement, to accommodate authorization servers that emit\niss\nbefore updating their metadata.\nA future revision of this specification is expected to upgrade authorization server inclusion of\niss\nfrom\nSHOULD\nto\nMUST\n. Implementers are encouraged to emit and validate\niss\nnow to ease that transition; client rejection behavior on\niss\nabsence will continue to be keyed on\nauthorization_response_iss_parameter_supported\nuntil that revision defines the upgrade path.\nAfter decoding the\niss\nvalue from the\napplication/x-www-form-urlencoded\nresponse per\nRFC 9207 Section 2.4\n, clients\nMUST NOT\napply scheme or host case folding, default-port elision, trailing-slash, or percent-encoding normalization (\nRFC 3986 Sections 6.2.2-6.2.3\n) before comparison.\nThis validation applies equally to error responses - on mismatch the client\nMUST NOT\nact on or display\nerror\n,\nerror_description\n, or\nerror_uri\n.\n​\nResource Parameter Implementation\nMCP clients\nMUST\nimplement Resource Indicators for OAuth 2.0 as defined in\nRFC 8707\nto explicitly specify the target resource for which the token is being requested. The\nresource\nparameter:\nMUST\nbe included in both authorization requests and token requests.\nMUST\nidentify the MCP server that the client intends to use the token with.\nMUST\nuse the canonical URI of the MCP server as defined in\nRFC 8707 Section 2\n.\n​\nCanonical Server URI\nFor the purposes of this specification, the canonical URI of an MCP server is defined as the resource identifier as specified in\nRFC 8707 Section 2\nand aligns with the\nresource\nparameter in\nRFC 9728\n.\nMCP clients\nSHOULD\nprovide the most specific URI that they can for the MCP server they intend to access, following the guidance in\nRFC 8707\n. While the canonical form uses lowercase scheme and host components, implementations\nSHOULD\naccept uppercase scheme and host components for robustness and interoperability.\nExamples of valid canonical URIs:\nhttps://mcp.example.com/mcp\nhttps://mcp.example.com\nhttps://mcp.example.com:8443\nhttps://mcp.example.com/server/mcp\n(when path component is necessary to identify individual MCP server)\nExamples of invalid canonical URIs:\nmcp.example.com\n(missing scheme)\nhttps://mcp.example.com#fragment\n(contains fragment)\nNote:\nWhile both\nhttps://mcp.example.com/\n(with trailing slash) and\nhttps://mcp.example.com\n(without trailing slash) are technically valid absolute URIs according to\nRFC 3986\n, implementations\nSHOULD\nconsistently use the form without the trailing slash for better interoperability unless the trailing slash is semantically significant for the specific resource.\nFor example, if accessing an MCP server at\nhttps://mcp.example.com\n, the authorization request would include:\n&resource=https%3A%2F%2Fmcp.example.com\nMCP clients\nMUST\nsend this parameter regardless of whether authorization servers support it.\n​\nAccess Token Usage\n​\nToken Requirements\nAccess token handling when making requests to MCP servers\nMUST\nconform to the requirements defined in\nOAuth 2.1 Section 5 “Resource Requests”\n.\nSpecifically:\nMCP client\nMUST\nuse the Authorization request header field defined in\nOAuth 2.1 Section 5.1.1\n:\nAuthorization: Bearer <access-token>\nNote that authorization\nMUST\nbe included in every HTTP request from client to server.\nAccess tokens\nMUST NOT\nbe included in the URI query string\nExample request:\nGET\n/mcp\nHTTP\n/\n1.1\nHost\n:\nmcp.example.com\nAuthorization\n:\nBearer eyJhbGciOiJIUzI1NiIs...\n​\nToken Handling\nMCP servers, acting in their role as an OAuth 2.1 resource server,\nMUST\nvalidate access tokens as described in\nOAuth 2.1 Section 5.2\n.\nMCP servers\nMUST\nvalidate that access tokens were issued specifically for them as the intended audience,\naccording to\nRFC 8707 Section 2\n.\nIf validation fails, servers\nMUST\nrespond according to\nOAuth 2.1 Section 5.3\nerror handling requirements. Invalid or expired tokens\nMUST\nreceive a HTTP 401\nresponse.\nMCP clients\nMUST NOT\nsend tokens to the MCP server other than ones issued by the MCP server’s authorization server.\nMCP servers\nMUST\nonly accept tokens that are valid for use with their\nown resources.\nMCP servers\nMUST NOT\naccept or transit any other tokens.\n​\nRefresh Tokens\nThis section provides guidance for MCP Clients and MCP Servers when handling or issuing\nrefresh tokens for both OAuth and OpenID Connect.\nMCP Clients\nthat desire refresh tokens:\nMUST\nkeep refresh tokens confidential in transit and storage as specified in\nOAuth 2.1 Section 4.3\nSHOULD\ninclude\nrefresh_token\nin their\ngrant_types\nclient metadata\nMAY\nadd\noffline_access\nto the\nscope\nparameter of the authorization and token requests when the Authorization Server metadata contains it in\nscopes_supported\nMUST NOT\nassume refresh tokens will be issued; the AS retains discretion\nMCP Servers\n(Protected Resources)\nSHOULD NOT\ninclude\noffline_access\nin\nWWW-Authenticate\nscope or Protected Resource Metadata\nscopes_supported\n, as refresh\ntokens are not a resource requirement.\n​\nError Handling\nServers\nMUST\nreturn appropriate HTTP status codes for authorization errors:\nStatus Code\nDescription\nUsage\n401\nUnauthorized\nAuthorization required or token invalid\n403\nForbidden\nInvalid scopes or insufficient permissions\n400\nBad Request\nMalformed authorization request\n​\nScope Challenge Handling\nThis section covers handling insufficient scope errors during runtime operations when\na client already has a token but needs additional permissions. This follows the error\nhandling patterns defined in\nOAuth 2.1 Section 5\nand leverages the metadata fields from\nRFC 9728 (OAuth 2.0 Protected Resource Metadata)\n.\n​\nRuntime Insufficient Scope Errors\nWhen a client makes a request with an access token with insufficient\nscope during runtime operations, the server\nSHOULD\nrespond with:\nHTTP 403 Forbidden\nstatus code (per\nRFC 6750 Section 3.1\n)\nWWW-Authenticate\nheader with the\nBearer\nscheme and additional parameters:\nerror=\"insufficient_scope\"\n- indicating the specific type of authorization failure\nscope=\"required_scope1 required_scope2\"\n- specifying the minimum scopes needed for the operation\nresource_metadata\n- the URI of the Protected Resource Metadata document (for consistency with 401 responses)\nerror_description\n(optional) - human-readable description of the error\nServer Scope Management\n: When responding with insufficient scope errors, servers\nSHOULD\ninclude the scopes needed to satisfy the current operation in the\nscope\nparameter, consistent with\nRFC 6750 Section 3.1\n.\nThe\nscope\nattribute describes the scopes necessary to access\nthe requested resource — servers are not required to include\nthe client’s previously granted scopes.\nWhatever scope-inclusion strategy a server adopts, servers\nSHOULD\ninclude all\nscopes required for the current operation in a single challenge.\nChallenging incrementally (returning one missing scope, then another\non the subsequent retry) forces multiple authorization round-trips\nfor a single operation and degrades user experience. The required\nscopes may be determined dynamically based on the specific request\narguments and context, but once determined, they should be emitted\ntogether.\nServers\nSHOULD\nbe consistent in their scope inclusion strategy to provide predictable behavior for clients.\nServers\nSHOULD\nconsider the user experience impact when determining which scopes to include in the\nresponse, as misconfigured scopes may require frequent user interaction.\nScope accumulation across operations is a client-side responsibility. See the\nStep-Up Authorization Flow\nfor the scope-union requirement.\nExample insufficient scope response:\nHTTP\n/\n1.1\n403\nForbidden\nWWW-Authenticate\n:\nBearer error=\"insufficient_scope\",\nscope=\"files:write\",\nresource_metadata=\"https://mcp.example.com/.well-known/oauth-protected-resource\",\nerror_description=\"File write permission required for this operation\"\n​\nStep-Up Authorization Flow\nClients will receive scope-related errors during initial authorization or at runtime (\ninsufficient_scope\n).\nClients\nSHOULD\nrespond to these errors by requesting a new access token with an increased set of scopes via a step-up authorization flow or handle the errors in other, appropriate ways.\nClients acting on behalf of a user\nSHOULD\nattempt the step-up authorization flow. Clients acting on their own behalf (\nclient_credentials\nclients)\nMAY\nattempt the step-up authorization flow or abort the request immediately.\nThe flow is as follows:\nParse error information\nfrom the authorization server response or\nWWW-Authenticate\nheader\nDetermine required scopes\nby computing the union of the\nclient’s previously requested scope set and the scopes from\nthe current challenge. This ensures previously granted\npermissions are preserved when servers emit per-operation\nscope challenges per\nRFC 6750 Section 3.1\n.\nClients\nMAY\nalso consult the\nScope Selection Strategy\nfor\ninitial scope selection guidance.\nInitiate (re-)authorization\nwith the determined scope set\nRetry the original request\nwith the new authorization no more than a few times and treat this as a permanent authorization failure\nClients\nSHOULD\nimplement retry limits and\nSHOULD\ntrack scope upgrade attempts to avoid\nrepeated failures for the same resource and operation combination.\nServers\nMUST\naccount for scope hierarchies, where a broader scope implies narrower ones, when\ndeciding whether a token is sufficient for an operation.\n​\nSecurity Considerations\nImplementations of this specification\nMUST\nfollow the normative security\nrequirements in\nSecurity Considerations\n,\ncovering token audience binding and validation, token theft, communication security,\nauthorization code protection, mix-up and confused deputy attacks, open redirection,\nand Client ID Metadata Document security.\n​\nMCP Authorization Extensions\nThere are several authorization extensions to the core protocol that define additional authorization mechanisms. These extensions are:\nOptional\n- Implementations can choose to adopt these extensions\nAdditive\n- Extensions do not modify or break core protocol functionality; they add new capabilities while preserving core protocol behavior\nComposable\n- Extensions are modular and designed to work together without conflicts, allowing implementations to adopt multiple extensions simultaneously\nVersioned independently\n- Extensions follow the core MCP versioning cycle but may adopt independent versioning as needed\nA list of supported extensions can be found in the\nMCP Authorization Extensions\nrepository.\nWas this page helpful?\nYes\nNo\nStreamable HTTP\nAuthorization Server Discovery\ngithub\ndiscord",
        "metadata": {
          "viewport": "width=device-width, initial-scale=1, viewport-fit=cover",
          "application-name": "Model Context Protocol",
          "generator": "Mintlify",
          "msapplication-config": "/mintlify-assets/_mintlify/favicons/mcp/ebiVJzri-bsiCfVZ/_generated/favicon/browserconfig.xml",
          "apple-mobile-web-app-title": "Model Context Protocol",
          "msapplication-TileColor": "#09090b",
          "og:title": "Authorization - Model Context Protocol",
          "og:url": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization",
          "og:site_name": "Model Context Protocol",
          "og:image": "https://raw.githubusercontent.com/modelcontextprotocol/docs/2eb6171ddbfeefde349dc3b8d5e2b87414c26250/images/og-image.png",
          "og:image:width": "1200",
          "og:image:height": "630",
          "og:type": "website",
          "twitter:card": "summary_large_image",
          "twitter:title": "Authorization - Model Context Protocol",
          "twitter:image": "https://raw.githubusercontent.com/modelcontextprotocol/docs/2eb6171ddbfeefde349dc3b8d5e2b87414c26250/images/og-image.png",
          "twitter:image:width": "1200",
          "twitter:image:height": "630"
        },
        "extraction": "article/main",
        "verified": false
      }
    },
    {
      "name": "Google Cloud Security & Identity",
      "url": "https://cloud.google.com/blog/products/identity-security",
      "focus": "ai_agent",
      "reason": "补查总 RSS 最新 20 条未覆盖的 Agent Identity、IAM 和工作负载身份文章",
      "page": {
        "ok": true,
        "final_url": "https://cloud.google.com/blog/products/identity-security",
        "text": "Security & Identity | Google Cloud Blog\nJump to Content\nCloud\nBlog\nContact sales\nGet started for free\nCloud\nBlog\nSolutions & technology\nAI & Machine Learning\nAPI Management\nApplication Development\nApplication Modernization\nChrome Enterprise\nCompute\nContainers & Kubernetes\nData Analytics\nDatabases\nDevOps & SRE\nMaps & Geospatial\nSecurity\nSecurity & Identity\nThreat Intelligence\nInfrastructure\nInfrastructure Modernization\nNetworking\nProductivity & Collaboration\nSAP on Google Cloud\nStorage & Data Transfer\nSustainability\nEcosystem\nIT Leaders\nIndustries\nFinancial Services\nHealthcare & Life Sciences\nManufacturing\nMedia & Entertainment\nPublic Sector\nRetail\nSupply Chain\nTelecommunications\nPartners\nStartups & SMB\nTraining & Certifications\nInside Google Cloud\nGoogle Cloud Next & Events\nGoogle Cloud Consulting\nGoogle Maps Platform\nGoogle Workspace\nDevelopers & Practitioners\nTransform with Google Cloud\nContact sales\nGet started for free\nSecurity & Identity\nHow Google Cloud achieves confidentiality, data integrity, availability, non-repudiation and authentication of your data.\nSecurity & Identity\nCloud CISO Perspectives: How Google monitors AI threats and advances AI defenses\nAI is driving 3 structural shifts in the threat landscape that CISOs must address. Learn about Google’s visibility into them — and how we’re solving them.\nBy Sandra Joyce • 10-minute read\nRead article\nHear directly from our Office of the CISO in your inbox\nGet original security insights, updates, and more from Google Cloud's Office of the CISO, twice a month!\nSubscribe today\nSecurity & Identity\nCloud CISO Perspectives: How cybersecurity startups can win CISOs\nBy Alicja Cade • 7-minute read\nSecurity & Identity\nGetting started with Mantis, our open-source bug finding-and-fixing harness\nBy Nick Galloway • 3-minute read\nSecurity & Identity\nGoogle Cloud partners deliver new security agents and AI defenses with Gemini Enterprise\nBy Vineet Bhan • 7-minute read\nA manufacturing blueprint for secure agentic AI\nAI and agents have arrived on the factory floor. Today’s CISOs and business leaders must balance innovation with precision, physical safety, and operational resilience.\nRead more\nHow Google Does It: An inside look at cybersecurity\nLearn how Google approaches some of today's most pressing security topics, challenges and concerns, straight from Google experts.\nView the collection\nSecurity & Identity\nStrengthen your CI/CD pipeline with new Secure Source Manager capabilities\nBy Logan Henriquez • 3-minute read\nSystems\nChanging the game: Using agentic AI to secure infrastructure code\nBy Andrés Lagar-Cavilla • 4-minute read\nSecurity & Identity\nGoogle named a Leader in the External Threat Intelligence Service Forrester Wave™\nBy Jayce Nichols • 4-minute read\nSecurity & Identity\nIntroducing new session management tools with native, granular controls\nBy Senzeni Mpofu • 3-minute read\nCustomers\nHow BlackLine simplifies perimeter policy intelligence with VPC Service Controls\nBy Pratik Bhangale • 4-minute read\nSecurity & Identity\nCloud CISO Perspectives: Tips on securing the water sector in the AI era\nBy Chris Sistrunk • 9-minute read\nNetworking\nSimplify your resilience testing strategy with Fault Injection Testing\nBy Toby Owen • 4-minute read\nAI infrastructure\nEmpowering autonomous agents with advanced security governance\nBy Doug Ko • 2-minute read\nSecurity & Identity\nCloud CISO Perspectives: Sticking to security fundamentals in the AI era\nBy Chris Betz • 6-minute read\nSecurity & Identity\nAnnouncing quantum-safe key import in Cloud KMS\nBy Alessio Buraggina • 3-minute read\nLoad more stories\nFooter Links\nFollow us\nGoogle Cloud\nGoogle Cloud Products\nPrivacy\nTerms\nCookies management controls\nHelp\nLanguage\n‪English‬\n‪Deutsch‬\n‪Français‬\n‪한국어‬\n‪日本語‬",
        "metadata": {
          "referrer": "origin",
          "viewport": "initial-scale=1, width=device-width",
          "track-metadata-page_hosting_platform": "blog_boq",
          "mobile-web-app-capable": "yes",
          "apple-mobile-web-app-capable": "yes",
          "application-name": "Google Cloud Blog",
          "apple-mobile-web-app-title": "Google Cloud Blog",
          "apple-mobile-web-app-status-bar-style": "black",
          "msapplication-tap-highlight": "no",
          "description": "Find all the latest news about Google Cloud and Security & Identity with customer stories, product announcements, solutions and more.",
          "robots": "max-image-preview:large",
          "og:title": "Security & Identity | Google Cloud Blog",
          "og:type": "website",
          "og:url": "https://cloud.google.com/blog/products/identity-security",
          "og:image": "https://storage.googleapis.com/gweb-cloudblog-publish/images/17_-_Security__Identity_NrORvDT.max-300x300.jpg",
          "og:description": "Find all the latest news about Google Cloud and Security & Identity with customer stories, product announcements, solutions and more.",
          "og:site_name": "Google Cloud Blog",
          "twitter:card": "summary_large_image",
          "twitter:url": "https://cloud.google.com/blog/products/identity-security",
          "twitter:title": "Security & Identity | Google Cloud Blog",
          "twitter:description": "Find all the latest news about Google Cloud and Security & Identity with customer stories, product announcements, solutions and more.",
          "twitter:image": "https://storage.googleapis.com/gweb-cloudblog-publish/images/17_-_Security__Identity_NrORvDT.max-300x300.jpg",
          "twitter:site": "@googlecloud"
        },
        "extraction": "visible-page",
        "verified": false
      }
    },
    {
      "name": "Microsoft Entra Blog",
      "url": "https://techcommunity.microsoft.com/blog/microsoft-entra-blog",
      "focus": "ai_agent",
      "reason": "关注 Entra Agent ID；测试的 RSS 返回 404 或空列表，网页打不开时通过官方域名检索补查并记录失败",
      "page": {
        "ok": false,
        "error": "HTTPError: HTTP Error 404: Not Found",
        "verified": false
      }
    },
    {
      "name": "Alibaba Cloud Agent Identity",
      "url": "https://www.alibabacloud.com/help/en/agentidentity/",
      "focus": "ai_agent",
      "reason": "关注阿里云智能体身份和凭证服务；静态文档只有核实日期、版本和实质变更后才算新增",
      "page": {
        "ok": true,
        "final_url": "https://www.alibabacloud.com/help/en/agentidentity/",
        "text": "Introduction to Agent Identity - Alibaba Cloud Document Center\nDocument Center\nall-products-head\nThis Product\nThis Product\nAll Products\nAgent Identity\nAgent Identity\nAll Products\nGetting Started\nWhat is Agent Identity?\nScenarios\nLimits\nShow more\nShow less\nAgent Identity Credential\nManage workload identities\nInbound\nOutbound\nObtain credentials\nShow more\nShow less\nUser Pool\nUser pool overview\nUser pool management\nSAML identity provider management\nUser management\nRole management\nClient management\nTutorials for typical identity provider setup\nShow more\nShow less\nAgent Permissions\nShow more\nShow less\nTutorials\nUse Agent Identity in Model Studio (Bailian) high-code\nSecurely access DingTalk from an agent\nShow more\nShow less\nDeveloper Reference\nShow more\nShow less\nAgent Identity is a foundational service in Alibaba Cloud’s Agentic AI ecosystem, managing identities and credentials for AI agents. It enables agents to securely access Alibaba Cloud and SaaS applications on behalf of users or themselves, providing the end-to-end security needed to transition AI agents from prototype to production-grade.\nconsole\nGetting Started\n学习路径\nMastering Agent Identity: From Basics to Advanced\nLearn\nGet Started\nWhat is Agent Identity?\nScenarios\nHands-on\nAgent Identity Credentials\nManage workload identities\nInbound\nOutbound\nObtain credentials",
        "metadata": {
          "spm-id": "a2c63",
          "data-spm": "a2c63",
          "aplus-core": "aplus.js",
          "aplus-ajax": "chksum",
          "aplus-waiting": "MAN",
          "aplus-pvhash": "1",
          "kloud:supported-langs": "en,zh,tc,ja,id,pt-BR,fr",
          "viewport": "width=device-width,initial-scale=1.0",
          "applicable-device": "pc,mobile",
          "aplus-rhost-v": "sg.mmstat.com",
          "aplus-rhost-g": "sg.mmstat.com",
          "keywords": "",
          "description": "Agent Identity is a foundational service in Alibaba Cloud’s Agentic AI ecosystem, managing identities and credentials for AI agents. It enables agents to securely access Alibaba Cloud and SaaS applications on behalf of users or themselves, providing the end-to-end security needed to transition AI agents from prototype to production-grade.",
          "og:title": "Agent Identity - Alibaba Cloud",
          "og:type": "website",
          "og:url": "https://www.alibabacloud.com/help/en/agentidentity/",
          "og:image": "https://img.alicdn.com/tfs/TB1xpNqnmslXu8jSZFuXXXg7FXa-1200-630.png_.webp",
          "og:description": "Agent Identity is a foundational service in Alibaba Cloud’s Agentic AI ecosystem, managing identities and credentials for AI agents. It enables agents to securely access Alibaba Cloud and SaaS applications on behalf of users or themselves, providing the end-to-end security needed to transition AI agents from prototype to production-grade."
        },
        "extraction": "visible-page",
        "verified": false
      }
    },
    {
      "name": "AWS AgentCore Identity",
      "url": "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity.html",
      "focus": "ai_agent",
      "reason": "补查产品发布说明与身份功能变更，静态文档不得作为今日新闻",
      "page": {
        "ok": true,
        "final_url": "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity.html",
        "text": "Provide identity and credential management for agent applications with Amazon Bedrock AgentCore Identity - Amazon Bedrock AgentCore\nView a markdown version of this page\nProvide identity and credential management for agent applications with Amazon Bedrock AgentCore Identity - Amazon Bedrock AgentCore\nDocumentation\nAmazon Bedrock AgentCore\nDeveloper Guide\nProvide identity and credential management for agent applications with Amazon Bedrock AgentCore Identity\nAmazon Bedrock AgentCore Identity is an identity and credential management service designed specifically for AI agents and automated workloads. It provides secure authentication, authorization, and credential management capabilities that enable agents and tools to access AWS resources and third-party services on behalf of users while helping to maintain strict security controls and audit trails. Agent identities are implemented as workload identities with specialized attributes that enable agent-specific capabilities while helping to maintain compatibility with industry-standard workload identity patterns. The service integrates natively with Amazon Bedrock AgentCore to provide identity and credential management for agent applications, including\nHost agent or tools with Amazon Bedrock AgentCore Runtime\nand\nAmazon Bedrock AgentCore Gateway: Securely connect tools and other resources to your Gateway\n.\nTopics\nOverview of Amazon Bedrock AgentCore Identity\nGet started with AgentCore Identity\nUsing the AgentCore Identity console\nManage workload identities with AgentCore Identity\nConfigure inbound JWT authorizer\nManage credential providers with AgentCore Identity\nProvider setup and configuration\nConfigure a consent portal\nConnect to private identity providers\nData protection in Amazon Bedrock AgentCore Identity\nTagging AgentCore Identity resources\nDocument Conventions\nPerformance optimization\nOverview\nDid this page help you? - Yes\nThanks for letting us know we're doing a good job!\nIf you've got a moment, please tell us what we did right so we can do more of it.\nDid this page help you? - No\nThanks for letting us know this page needs work. We're sorry we let you down.\nIf you've got a moment, please tell us how we can make the documentation better.",
        "metadata": {
          "viewport": "width=device-width,initial-scale=1",
          "assets_root": "/assets",
          "target_state": "identity",
          "default_state": "identity",
          "description": "Amazon Bedrock AgentCore Identity is an identity and credential management service designed specifically for AI agents and automated workloads. It provides secure authentication, authorization, and credential management capabilities that enable agents and tools to access AWS resources and third-party services on behalf of users while helping to maintain strict security controls and audit trails. Agent identities are implemented as workload identities with specialized attributes that enable agent-specific capabilities while helping to maintain compatibility with industry-standard workload identity patterns. The service integrates natively with Amazon Bedrock AgentCore to provide identity and credential management for agent applications, including",
          "deployment_region": "IAD",
          "product": "Amazon Bedrock AgentCore",
          "guide": "Developer Guide",
          "guide-locale": "en_us",
          "tocs": "toc-contents.json",
          "feedback-item": "bedrock-agentcore",
          "this_doc_product": "Amazon Bedrock AgentCore",
          "this_doc_guide": "Developer Guide",
          "uiVersion": "2024.10",
          "pdf": "/pdfs/bedrock-agentcore/latest/devguide/bedrock-agentcore-dg.pdf#identity",
          "rss": "bedrock-agentcore-dg.rss",
          "forums": "https://repost.aws/search/content?globalSearch=Amazon Bedrock AgentCore",
          "feedback": "https://docs.aws.amazon.com/forms/aws-doc-feedback?hidden_service_name=bedrock-agentcore&topic_url=https://docs.aws.amazon.com/en_us/bedrock-agentcore/latest/devguide/identity.html",
          "feedback-yes": "feedbackyes.html?topic_url=https://docs.aws.amazon.com/en_us/bedrock-agentcore/latest/devguide/identity.html",
          "feedback-no": "feedbackno.html?topic_url=https://docs.aws.amazon.com/en_us/bedrock-agentcore/latest/devguide/identity.html"
        },
        "extraction": "visible-page",
        "verified": false
      }
    }
  ],
  "new_items": 0
}