身份认证日报 · 2026-10-07

采集时间：2026-10-07T19:28:39.961487+08:00 · 最近 24 小时 · 6 条 · 来源去重

Passkey / FIDO · MFA · OAuth / OIDC · AI Agent 身份与授权 · 身份安全漏洞 · 行业动态

Announcing MCP Toolbox Java SDK v1.0: Agentic data access for the enterprise

Google Cloud · Agent 身份 · 2026-10-07T03:00:00+08:00 · AI Agent · 已采集

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

来源摘录和自动提取正文均不等于人工核验。

自动提取的正文

Developers & Practitioners Announcing MCP Toolbox Java SDK v1.0: Agentic data access for the enterprise October 7, 2026 Abirami Sukumaran Staff Developer Advocate, Google 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 new in Java SDK v1.0, show you a real-world example, and help you get started with your own implementation. MCP: The universal interface Today, developers face a compounding integration bottleneck: if you have N different AI models and M enterprise data sources, you must build, secure, and maintain N × M bespoke, 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. Eliminating 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. What's new in Java SDK v1.0: Built for production workloads When we announced the public Beta for 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. The 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: Transport layer abstraction & HttpMcpTransport : We introduced a clean transport layer abstraction alongside HttpMcpTransport . This feature decouples the core protocol logic from underlying HTTP clients, making it easy to swap network implementations or customize connection pooling. Decoupled client authentication : To simplify enterprise security compliance, client authentication is now decoupled using CredentialsProvider and AuthMethods classes . 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). Default parameter support : Native support for default values in tool parameters, reducing prompt payload sizes and enhancing agent reliability. Pruning bound parameters : Sensitive parameters that are bound server-side (like tenant_id ) are now automatically stripped from exposed tool definitions so the LLM can't manipulate them. Version selection & session tracking : Standardized MCP version selection and robust session tracking ensure consistent protocol negotiation and conversation-state lifecycles. HTTP credential exposure warnings : Added built-in detection that warns you at runtime when credentials are about to travel over a plaintext HTTP connection. Generic client headers map : Easily attach custom corporate proxy headers, transaction tracing IDs, or correlation metadata to all outgoing requests. Get started with the Java SDK v1.0 We designed the MCP Toolbox Java SDK to be frictionless for enterprise teams. Just add the following dependency to your pom.xml : Loading... <dependency>

&lt;groupId&gt;com.google.cloud.mcp&lt;/groupId&gt;

&lt;artifactId&gt;mcp-toolbox-sdk-java&lt;/artifactId&gt;

&lt;version&gt;1.0.0&lt;/version&gt;

</dependency> Real-world example: The autonomous transit concierge To demonstrate the power of the Java SDK combined with AlloyDB, let's look at an enterprise use case. Meet Cymbal Transit , a fictitious intercity bus network. Customers don't want to click through nested dropdown menus to plan a trip. They want to ask: "I need to get from New York to Boston tomorrow morning. Can I bring my Golden Retriever? If so, book me the fastest trip." To 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. The foundation: AlloyDB schema with native embeddings We used AlloyDB for this implementation because it handles relational data and high-dimensional vectors natively. Set up your database tables with these statements: lang-sql Loading... -- Enable necessary extensions for semantic search and embeddings

CREATE EXTENSION IF NOT EXISTS vector;

CREATE EXTENSION IF NOT EXISTS google_ml_integration;

-- Table 1: Transit Policies (Unstructured Data for RAG)

CREATE TABLE transit_policies (

policy_id SERIAL PRIMARY KEY,

category VARCHAR(50),

policy_text TEXT,

policy_embedding vector(768)

);

-- Table 2: Intercity Bus Schedules (Structured Data)

CREATE TABLE bus_schedules (

trip_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),

origin_city VARCHAR(100),

destination_city VARCHAR(100),

departure_time TIMESTAMP,

arrival_time TIMESTAMP,

available_seats INT DEFAULT 50,

ticket_price DECIMAL(6,2)

);

-- Table 3: Booking Ledger (Transactional Action Data)

CREATE TABLE bookings (

booking_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),

trip_id UUID REFERENCES bus_schedules(trip_id),

passenger_id VARCHAR(100),

status VARCHAR(20) DEFAULT 'CONFIRMED',

booking_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP

); Mapping intents to SQL: The tools.yaml The MCP Toolbox lets you define custom tools securely. Rather than granting the LLM direct database access, a tools.yaml configuration maps natural language intents directly to parameterized, safe queries: Loading... kind: source

name: alloydb

type: alloydb-postgres

project: my-project

region: us-central1

cluster: my-cluster

instance: my-instance

database: postgres

kind: tool

name: query-schedules

type: postgres-sql

source: alloydb

description: Find available bus schedules between cities.

parameters:

name: origin
type: string
description: The departure city name.
name: destination
type: string
description: The arrival city name.
name: limit
type: integer
description: Maximum number of schedules to return.
default: 5

statement: |

SELECT CAST(trip_id AS TEXT) AS trip_id, departure_time, ticket_price

FROM bus_schedules

WHERE lower(origin_city) = lower($1) AND lower(destination_city) = lower($2)

ORDER BY departure_time ASC

LIMIT $3 For the complete YAML file, see the tools.yaml file in the mcp-toolbox-sdk-java repository. Stateful agent architecture in Spring Boot The 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. Using 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: A declarative agent interface that manages the prompt, tools, and conversational memory via an HTTP session. A tool execution service that routes agent requests directly to the MCP Toolbox server. Loading... interface TransitAgent {

@SystemMessage({

    "You are the Cymbal Transit Concierge.",

    "Use the 'querySchedules' tool for finding schedules.",

    "Use 'bookTicket' to execute transactions.",

    "Use 'searchPolicies' to look up luggage and pet rules."

})

String chat(@MemoryId String sessionId, @UserMessage String userMessage);

}

@Service

class TransitAgentTools {

// These methods automatically invoke our MCP Toolbox server!

@Tool("Query specific schedules between an origin and destination city.")

public String querySchedules(String origin, String destination) { ... }

@Tool("Book a ticket for a passenger.")

public String bookTicket(String tripId, String passengerName) { ... }

@Tool("Search transit policies for luggage and pet rules.")

public String searchPolicies(String query) { ... }

} Notice how the @MemoryId annotation 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. By pairing the MCP Toolbox Java SDK with LangChain4j, we achieve clean separation of concerns and effortless state management: Zero-boilerplate session management : The @MemoryId String sessionId parameter binds conversation history directly to the user's HTTP session. Declarative agent contract : The TransitAgent interface defines the model's persona and system instructions without complex prompt templating. Type-safe tool execution : The TransitAgentTools Spring service wraps remote MCP database tools as native Java methods. This 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. Connecting the dots: Listing, invoking, and executing tools in Java v1.0 Now let's look under the hood of the TransitAgentTools interface. Inside those LangChain4j @Tool methods on our Spring @Service , the MCP Toolbox Java SDK handles the heavy lifting—bridging your Java service methods to the MCP tools defined in the tools.yaml file. In just a few lines of type-safe code, we can initialize our client using the new v1.0 decoupled authentication and headers abstractions: Loading... // 1. Initialize the Client with Decoupled Auth and Custom Headers (v1.0)

String serviceUrl = "https://toolbox-my-project-uc.a.run.app/mcp";

McpToolboxClient mcpClient = McpToolboxClient.builder()

.baseUrl(serviceUrl)

.credentialsProvider(new GoogleCredentialsProvider(serviceUrl)) // Decoupled OIDC credentials

.headers(Map.of( // Generic client headers

    "X-Correlation-ID", "enterprise-session-abc123",

    "X-Client-Platform", "Spring-Boot"

))

.build();

// 2. Listing Discoverable Tools

mcpClient.listTools().thenAccept(tools -> {

System.out.println("Successfully discovered " + tools.size() + " tools.");

});

// 3. Invoking a Tool (Read-Only Data with Default Parameter Support)

// "limit" is omitted: the SDK fills it from the default in the tool definition

String schedules = mcpClient.loadTool("query-schedules")

.thenCompose(tool -&gt; tool.execute(Map.of(

    "origin", "New York",

    "destination", "Boston")))

.join().text();

// 4. Executing a Transactional Tool (Using Bound Parameters)

AuthTokenGetter toolAuthGetter = () -> CompletableFuture.completedFuture(myIdToken);

String bookingConfirmation = mcpClient.loadTool("book-ticket", Map.of("google_auth", toolAuthGetter))

// Bind the authenticated user context securely. bindParam returns a new immutable

// Tool, and the bound parameter is pruned from the definition exposed to the LLM!

.thenCompose(tool -&gt; tool.bindParam("passenger_name", "Jane Doe")

    // Execute the mutable transaction

    .execute(Map.of("trip_id", "123e4567-e89b-12d3-a456-426614174000")))

.join().text();

Secure by default: authentication and deployment Moving 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. Application Default Credentials (ADC) & safety By using the GoogleCredentialsProvider service , 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. Deploying the fleet to Cloud Run Because 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. To set up and configure Toolbox on Cloud Run, download the open-source MCP Toolbox for Databases and then follow the deployment guide . Get started today With 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 implementation steps will help you get started . Step 1: Add the Dependency To start building with the SDK, add the following dependency to your Maven project's pom.xml file: Loading... <dependency>

    &lt;groupId&gt;com.google.cloud.mcp&lt;/groupId&gt;

    &lt;artifactId&gt;mcp-toolbox-sdk-java&lt;/artifactId&gt;

    &lt;version&gt;1.0.0&lt;/version&gt;

&lt;/dependency&gt;

Step 2: Explore Resources & Demos GitHub Repository : Java SDK for interacting with the MCP Toolbox for Databases Official Documentation : MCP Toolbox for Databases Demo Application : To experience the Java SDK V1.0 for MCP Toolbox latest, try the sample application Cymbal transit project . Gradle implementation If your team uses Gradle instead of Maven, remember they will need to translate this dependency: Loading... implementation 'com.google.cloud.mcp:mcp-toolbox-sdk-java:1.0.0' Automatic version tracking I f you copy this setup into automated internal repositories, k eep the XML comment  intact. It's required by the release manager's deployment scripts to automatically bump versions. Now 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! Posted in Developers & Practitioners Related articles Developers & Practitioners Networking for AI inference model serving - GKE only and for all other backends By Ammett Williams • 6-minute read Containers & Kubernetes GKE CPU startup boost: Accelerate app starts without over-provisioning By Abdel Sghiouar • 6-minute read Developers & Practitioners Democratizing Managed Lustre with lower cost and frictionless development By Barak Epstein • 6-minute read Developers & Practitioners Introducing the Server Side Cloud Swift SDK By Karl Weinmeister • 6-minute read

Improving SPIRE security and resiliency with AWS managed services

AWS Security · 2026-10-07T02:52:25+08:00 · 身份认证 · 已采集

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 […]

来源摘录和自动提取正文均不等于人工核验。

自动提取的正文

AWS Security Blog Improving SPIRE security and resiliency with AWS managed services by Brendan Paul and Meg Peddada on 06 OCT 2026 in Advanced (300) , Security, Identity, & Compliance , Technical How-to Permalink Comments Share 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 turning to SPIFFE (Secure Production Identity Framework for Everyone) as 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 bottom turtle problem: the circular dependency where protecting one credential requires yet another credential. SPIRE (the SPIFFE Runtime Environment) is 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: Where cryptographic signing keys for workload identities are managed How to ensure availability and resiliency of the workload identity registry How the SPIRE Certificate Authority integrates into the existing enterprise PKI How workloads without direct connectivity to the SPIRE server validate identities How workload identities are delivered to serverless environments How fine-grained authorization based on SPIFFE IDs is enforced In 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 Github Repository that guides you through the deployment of the reference architecture. To learn the core concepts the SPIFFE framework, take a moment to familiarize yourself with the SPIFFE documentation . SPIRE background A SPIRE deployment is comprised of at least one SPIRE Server, at least one SPIRE Agent, and at least one workload. Figure 1: SPIRE high-level architecture The SPIRE Server is 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: RegistrationAPI : Create, update, and delete registration entries that define which workloads are entitled to specific SPIFFE IDs based on selectors (for example, Kubernetes namespace, Unix UID). DataStore : 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. KeyManager : Controls how the server manages private keys used to sign X.509-SVIDs and JWT-SVIDs. BundlePublisher : Publishes the local trust bundle to a store. The trust bundle is an object containing a trust domain’s cryptographic keys UpstreamAuthority : Dictates which root certificate authority is used to sign the SPIRE certificate authority (CA) certificate The SPIRE Agent is distributed across your workloads, whether they run on Amazon Elastic Compute Cloud (Amazon EC2) instances, Amazon Elastic Container Service (Amazon ECS) containers, or Amazon Elastic Kubernetes Service (Amazon EKS) Pods. The SPIRE Agent handles: WorkloadAPI : Exposes the workload API to workloads, which enable workloads to retrieve their SVIDs and trust bundles from the SPIRE server. NodeAttestation : SPIRE requires that each agent attest and verify itself. WorkloadAttestation : The SPIRE agent collects workload metadata to determine its identity. SVIDStore : The SPIRE Agent also stores SVIDs in other destinations, such as AWS Secrets Manager or HashiCorp Vault making them available for workloads running in serverless environments. After the server and agent are deployed, applications retrieve short-lived SPIFFE Verifiable Identity Documents ( X.509 Certificates or JSON Web Tokens (JWTs) ) using the workload API. How to use AWS managed services for core SPIRE functions In 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. Figure 2: SPIFFE architecture using AWS managed services To deploy the infrastructure required to follow along with this post, follow the deployment process in the Github Repository . Note : For each managed service, there’s a parameter in the source AWS CloudFormation templates that you can use to specify whether to provision the resource. For example, if you already have an AWS Private Certificate Authority (AWS Private CA) certificate authority deployed in your environment, you can use that for your SPIRE implementation and avoid provisioning a new certificate authority. SPIRE Key Manager using AWS KMS The 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. By 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. By using the AWS KMS plugin for SPIRE , you bring the security benefits of AWS KMS to your SPIRE implementation. HSMs : AWS KMS uses hardware security modules (HSMs) that have been validated under FIPS 140-3 Level 2 Key protection : 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 Comprehensive auditing : Each request to use the keys for signing must be authenticated using Signature Version 4 (SigV4) and is audited and logged in AWS CloudTrail Fine-grained access control: Use AWS KMS Key Policies to restrict access to your signing keys This configuration block indicates to SPIRE that AWS KMS keys are used to sign our SVIDs: KeyManager "aws_kms" { plugin_data { region = "<your-region>" key_identifier_file = "./key_metadata" } } This code block exists in the SPIRE server configuration deployed in the Github repository. SPIRE datastore using Amazon Aurora The 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 Amazon Aurora . By doing this, you can decouple the database from the server and offload the operational overhead of managing the datastore to AWS. Benefits: High availability : Automatic failover and multi-Availability Zone deployments Automated backups : Point-in-time recovery and automated backup retention Scalability : Scale compute and storage independently Security : Encryption at rest and in transit, with AWS Identity and Access Management (IAM) Monitoring : Built-in performance insights and enhanced monitoring Reduced operational burden : Automated patching, maintenance, and updates To do this, the CloudFormation stack provisions: An Aurora PostgreSQL Cluster A database user with the capability to authenticate through AWS IAM Network connectivity between your SPIRE Server and the database After the sample finishes deployment, the configuration in the SPIRE server is changed from the default: DataStore "sql" {

plugin_data {

database_type = "sqlite3"

connection_string = "/opt/spire/data/server/datastore.sqlite3"

}

} To: DataStore "sql" {

plugin_data {

database_type "aws_postgres" {

region = "<region>"

}

connection_string = "dbname=<dbname> user=spiffe host=<your_db_endpoint> port=<your_port>"

}

} For more information, see Datastore SQL Plugin . SPIRE certificate authority using AWS Private Certificate Authority The 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. Using 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: HSM-backed root of trust : The root of trust of your CA hierarchy is backed by fully managed, FIPS 140-2 Level 3 validated hardware security modules Non-exportable private keys : The private keys for the root CA can’t be exported Fully Managed Certificate Revocation Lists and OCSP endpoint : In case the issuing CA certificate needs to be revoked Note : If the SPIRE CA certificate will be signed by an issuing CA, you need to ensure that the path length of 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. After the sample deployment is complete, the configuration of the SPIRE server configuration includes the UpstreamAuthority plugin to use your AWS Private CA certificate authority as the root of trust. UpstreamAuthority "aws_pca" {

plugin_data {

region = "<aws_region>"

certificate_authority_arn = "<your_pca_arn>"

ca_signing_template_arn = "arn:aws:acm-pca:::template/SubordinateCACertificate_PathLen0/V1"

}

} For more information, see the AWS Private CA upstream authority plugin documentation . SPIRE bundle publisher using Amazon S3 In 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. The SPIRE Server supports exposing an endpoint containing this trust bundle or publishing the bundle to Amazon Simple Storage Service (Amazon S3) . By publishing the bundle to Amazon S3, you can: Decouple : Decouple bundle access from the SPIRE server availability Continuous validation : Allow destination workloads to continually validate source workload identities without requiring network access to the SPIRE server Global distribution : Distribute the trust bundle using Amazon CloudFront , improving performance through the CloudFront global edge network with over 750 Points of Presence Reduced load : Offload trust bundle retrieval traffic from the SPIRE server Version control : Maintain historical versions of trust bundles with S3 versioning The following is a sample configuration for this plugin: BundlePublisher "aws_s3" {

plugin_data {

region = "<your_bucket_region>"

bucket = "<your_bucket_name>"

object_key = "<your_bundle_name"

format = "spiffe"

}

} For more information, see S3 Bundle Publisher Plugin Reference . SPIRE Agent SVID store using Secrets Manager In 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 AWS Lambda or an AI agent running in Amazon Bedrock AgentCore Runtime . In these scenarios, use the SVID store plugin to push the SVID to Secrets Manager . In 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 AWS Secrets Manager SVIDStore Plugin . Benefits: Encryption at rest : Secrets are encrypted by default using AWS managed or customer-managed AWS KMS keys Broad integration : Integrations with multiple compute types, including AWS Secrets Manager Lambda Extension , Amazon ECS , Amazon EMR , and 52 other AWS services Client-side caching : Secrets Manager provides client-side caching libraries to improve performance and reduce API calls Multi-region replication : Built-in multi-Region replication functionality for workloads with multi-region requirements Fine-grained access control : Use resource policies to control which workloads access which SVIDs Audit trail : All secret access is logged in CloudTrail This plugin is configured in the agent , as opposed to the SPIRE server. A reference for the specific permissions required are in the plugin Github repository . In the sample code, see the configuration in the following agent.conf file: SVIDStore "aws_secretsmanager" {

plugin_data {

region = "<your_region>"

}

} When you need to specify a given workload’s SVID to be pushed to Secrets Manager, you add the storeSVID and 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: kubectl exec -n spire spire-server-<postfix>-- \

/opt/spire/bin/spire-server entry create \

-spiffeID spiffe://example.org/<workload_name> \

-parentID spiffe://example.org/ns/spire/sa/spire-agent \

-selector aws_secretsmanager:secretname:<workload_name> \

-storeSVID Fine-grained access control using Verified Permissions Up 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 Amazon Verified Permissions . Verified Permissions is a scalable, fine-grained permissions management and authorization service that helps you build secure applications. You can use it to: Define declarative policies : Use Cedar policy language , which provides human-readable, declarative access control rules Centralize policy management : Separate authorization logic from application code Take advantage of the straightforward policy authoring, formal verification capabilities, and performance benefits of Cedar Make real-time decisions : Evaluate authorization requests in real-time based on multiple factors including user identity, workload identity (SPIFFE ID), resource attributes, and contextual information Integrate with identity providers : Support for OpenID Connect (OIDC) providers, enabling validation of JWT tokens including JWT-SVIDs With 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 policy store, an identity source , and authorization policies . The github sample creates a policy store on your behalf and sets up the necessary infrastructure to have SPIRE serve as an identity source for your policy store. You will need policies to enforce fine grained authorization. The following sample policy forbids a specific workload from taking any action: forbid(

principal,

action,

resource

)

when {

context has sub &&

context.sub like "spiffe://example.org/forbidden-workload/*"

}; Or conversely allows a specific workload to take actions: permit(

principal,

action,

resource

)

when {

context has sub &&

context.sub like "spiffe://example.org/allowed-workload/*"

}; Experiment with these policies as you build on top of your SPIRE infrastructure. Conclusion This 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. If you’re interested in learning SPIFFE on AWS, check out our SPIRE on AWS github sample or the SPIFFE and SPIRE on AWS Workshop for hands-on learning. If you have feedback about this post, submit comments in the Comments section below. Brendan Paul Brendan 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. Meg Peddada Meg 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. TAGS: Security Blog Loading comments…

Identity-aware AI data agents with AWS Lake Formation and Trusted Identity Propagation

AWS Security · 2026-10-07T00:07:06+08:00 · AI Agent · 已采集

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 […]

来源摘录和自动提取正文均不等于人工核验。

自动提取的正文

AWS Security Blog Identity-aware AI data agents with AWS Lake Formation and Trusted Identity Propagation by Thiyagarajan Mani , Mihir Borkar , Philippe Duplessis-Guindon , and Umang Khambhalikar on 06 OCT 2026 in Advanced (300) , AWS IAM Identity Center , AWS Lake Formation , Security, Identity, & Compliance , Technical How-to Permalink Comments Share 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 to data and constructs a query. The tool runs under its own AWS Identity and Access Management (IAM) role, so AWS Lake Formation sees 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). In 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 AWS CloudTrail records the actual person who accessed the data. In this post, you learn how to: Set up per-user data access controls for AI agents querying your lakehouse without rewriting your existing Lake Formation governance policies by configuring Amazon Bedrock AgentCore to carry each user’s identity through trusted identity propagation (TIP). Ensure auditability and compliance by performing a server-side token exchange inside AWS Lambda that converts the identity token into Lake Formation credentials scoped to the real user, with CloudTrail recording every query. Validate the pattern end-to-end by testing with multiple users and confirming per-user query results and CloudTrail audit evidence. The building blocks in this post, OAuth 2.0 token delegation, AWS IAM Identity Center , 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 Amazon Bedrock AgentCore configurations that achieve that. Whether 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. Solution overview Figure 1: Solution overview With 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. Two tokens travel through the system. An access_token authenticates the request at each trust boundary ( Bedrock AgentCore Runtime , Bedrock AgentCore Gateway ). An id_token carries your identity and is exchanged, server-side, for the identity context that Lake Formation evaluates. A separate TIP role carries only the IAM permissions needed to call service APIs, it has no Lake Formation data grants. Lake Formation evaluates only the propagated user identity, not the TIP role. The request flow is: User to UI: The user authenticates with an OpenID Connect (OIDC) identity provider (IdP). This post uses Amazon Cognito , but you can use any OIDC provider, such as Okta. The UI receives an id_token and an access_token . UI to Bedrock AgentCore Runtime: The UI calls the agent running in AgentCore Runtime over HTTPS. The access_token goes in the standard Authorization header. The id_token goes in a custom header: X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken . The HTTP body contains only the user’s prompt. AgentCore Runtime to agent code: The runtime validates the access_token against the configured JSON Web Token (JWT) authorizer, then passes the request to the agent container with both headers accessible through context.request_headers . Agent to Bedrock AgentCore Gateway: The agent opens a Model Context Protocol (MCP) connection to an AgentCore gateway, including both headers on the connection. The AgentCore gateway validates the access_token and forwards the custom header to its Lambda target. AgentCore Gateway to Lambda: The propagated headers arrive in context.client_context.custom[‘bedrockAgentCorePropagatedHeaders’] . Lambda to the data layer: Lambda validates the id_token , exchanges it for an identity context, assumes a role with that context, and runs the Amazon Athena query under the user’s identity. Lake 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 onBehalfOf entry identifying the human. Now 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. Prerequisites This post assumes you have the working knowledge of OAuth 2.0, IAM, and Lake Formation grants. An IAM Identity Center instance with a trusted token issuer (TTI) configured to accept your OIDC IdP’s tokens. An OAuth Application in IAM Identity Center configured for CreateTokenWithIAM with the JWT Bearer grant. Lake Formation governing your AWS Glue Data Catalog, with grants already assigned to users or groups. An Athena workgroup and an Amazon Simple Storage Service (Amazon S3) bucket for query results. An OIDC IdP. The reference implementation uses Amazon Cognito as 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. This 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. The three Bedrock AgentCore configuration steps Three Bedrock AgentCore features make this pattern work. Together they form the chain of custody for the user’s id_token from the moment it arrives at the Bedrock AgentCore Runtime to the moment Lambda uses it. Configure the runtime request header allow list Bedrock AgentCore Runtime doesn’t pass request headers into the agent container by default. You opt in by declaring an allow list, either through agentcore configure or directly in the runtime configuration:

.bedrock_agentcore.yaml

request_header_configuration: requestHeaderAllowlist: - Authorization - X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken AgentCore Runtime supports two types of forwarded headers: The standard Authorization header for OAuth inbound JWT authentication ( access_token ), and Custom headers prefixed with X-Amzn-Bedrock-AgentCore-Runtime-Custom- The id_token in this pattern uses a custom header. Inside the agent, the allow listed headers arrive as a dictionary object on the request context. The following Python code runs in the agent container: from bedrock_agentcore.runtime import BedrockAgentCoreApp

ID_TOKEN_HEADER = "X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken" app = BedrockAgentCoreApp()

@app.entrypoint def invoke(payload, context): request_headers = getattr(context, "request_headers", None) or {}

id_token = ""
access_token = ""
for key, value in request_headers.items():
    if key.lower() == ID_TOKEN_HEADER.lower():
        id_token = value
    elif key.lower() == "authorization":
        access_token = value.replace("Bearer ", "")

# ... build MCP headers and call the Gateway

The agent code reads the id_token from 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. Key takeaway: The runtime allow list is the first gate. Without it, the id_token doesn’t reach your agent code. Configure AgentCore Gateway metadata for header propagation An 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 metadataConfiguration.allowedRequestHeaders on the target: from aws_cdk import aws_bedrockagentcore as agentcore

self.gateway_target = agentcore.CfnGatewayTarget( self, "AthenaTarget", name="athena-executor", gateway_identifier=self.gateway.attr_gateway_identifier, target_configuration=agentcore.CfnGatewayTarget.TargetConfigurationProperty( mcp=agentcore.CfnGatewayTarget.McpTargetConfigurationProperty( lambda_=agentcore.CfnGatewayTarget.McpLambdaTargetConfigurationProperty( lambda_arn=lambda_function_arn, tool_schema=... # execute_athena_query ), ), ), metadata_configuration=agentcore.CfnGatewayTarget.MetadataConfigurationProperty( allowed_request_headers=["X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken"], ), ... ) Notice that the tool schema doesn’t include an id_token parameter; there’s no token parameter on any tool. The FM doesn’t see, select, or pass an id_token because the token isn’t part of the tool’s contract. It travels parallel to the tool call, on the HTTP connection, through metadataConfiguration . This is a critical property for security. If you put the id_token in 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. Key takeaway: The metadataConfiguration of the AgentCore gateway is the second gate. It controls which headers cross from the agent into the Lambda function without touching the tool schema. Read propagated headers in Lambda On the Lambda side, the propagated header arrives not in the event body but in the client context, under a specific key. The following Python code runs in the Lambda function: ID_TOKEN_HEADER = "X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken"

def lambda_handler(event, context): client_ctx = getattr(context.client_context, "custom", {}) or {} propagated_headers = client_ctx.get("bedrockAgentCorePropagatedHeaders", {}) id_token = propagated_headers.get(ID_TOKEN_HEADER)

if not id_token:
    return {"statusCode": 400, "body": {"error": "missing id_token"}}

# Tool arguments from the agent's call (no id_token here)
query = event["query"]
database = event["database"]
workgroup = event["workgroup"]
output_location = event["output_location"]

# ... validate token, exchange, run query

The event dictionary contains the tool’s declared parameters and nothing else. You reach the id_token only through context.client_context.custom[‘bedrockAgentCorePropagatedHeaders’] . That’s the handoff point. Key takeaway: The id_token arrives 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. Perform the server-side token exchange After Lambda has the id_token , it validates the token and exchanges it for an identityContext . 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. import boto3, jwt, time

def exchange_and_assume(id_token: str, user_sub: str): # 1. Validate id_token against the OIDC IdP's JWKS. claims = validate_id_token(id_token) # signature, exp, aud, iss, token_use

# 2. Exchange for an Identity Center identityContext.
sso_oidc = boto3.client("sso-oidc")
resp = sso_oidc.create_token_with_iam(
    clientId=OAUTH_APPLICATION_ARN,
    grantType="urn:ietf:params:oauth:grant-type:jwt-bearer",
    assertion=id_token,
)
identity_context = resp["awsAdditionalDetails"]["identityContext"]

# 3. AssumeRole with ProvidedContexts
sts = boto3.client("sts")
assumed = sts.assume_role(
    RoleArn=TIP_ROLE_ARN,
    RoleSessionName=f"agent-tip-{user_sub[:8]}-{int(time.time())}",
    ProvidedContexts=[{
        "ProviderArn": "arn:aws:iam::aws:contextProvider/IdentityCenter",
        "ContextAssertion": identity_context,
    }],
)
creds = assumed["Credentials"]
return boto3.Session(
    aws_access_key_id=creds["AccessKeyId"],
    aws_secret_access_key=creds["SecretAccessKey"],
    aws_session_token=creds["SessionToken"],
)

Two properties come out of this exchange: The identityContext is created and consumed inside a single Lambda invocation. It doesn’t get returned to the agent, the gateway, or the UI. The resulting boto3.Session holds 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. Everything after this, including the Athena query and result formatting, is standard boto3. Configure Lake Formation grants You need one grant to the IAM Identity Center user or group. That’s the whole story at the Lake Formation layer. aws lakeformation grant-permissions
--principal DataLakePrincipalIdentifier=arn:aws:identitystore:::user/<USER_ID>
--resource '{"Table":{"DatabaseName":"iceberg_db","Name":"trip_details"}}'
--permissions SELECT This 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. Understanding the TIP role: The TIP role that Lambda assumes has no Lake Formation data grants. It holds only IAM permissions to call the service APIs: athena:* for query runs, glue:* for catalog reads, lakeformation:GetDataAccess for the query plan handshake, and Amazon S3 access for the Athena output bucket. When Lambda assumes this role with an identityContext attached through ProvidedContexts , Lake Formation evaluates only the propagated user identity against its grants. The role itself is transparent to the authorization decision. In the more common agent runs as a role pattern, 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. Test the pattern end-to-end Two users, same question, different outcomes. User A has SELECT on trip_details . They ask the agent for five records from the table. Figure 2: Five records are requested and returned by the agent User B has no grant on trip_details . They ask the same question. Figure 3: User doesn’t have access to the data No code changed between the two interactions. No parameter was toggled. Lake Formation made the decision based on the propagated identity. The CloudTrail record for the AssumeRole call shows the delegation: { "eventSource": "sts.amazonaws.com", "eventName": "AssumeRole", "requestParameters": { "roleArn": "arn:aws:iam::<ACCOUNT_ID>:role/<TIP_ROLE_NAME>", "roleSessionName": "agent-tip-<user_sub_prefix>-<timestamp>", "providedContexts": [{ "providerArn": "arn:aws:iam::aws:contextProvider/IdentityCenter", "contextAssertion": "<identity-context-assertion>" }] }, "userIdentity": { "type": "AssumedRole", "onBehalfOf": { "userId": "<IDENTITY_STORE_USER_ID>", "identityStoreArn": "arn:aws:identitystore::<ACCOUNT_ID>:identitystore/<ID>" } } } The onBehalfOf block 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. Security properties Four properties follow from this architecture. These are the core value propositions of the identity-aware pattern: The id_token never reaches the foundation model: It travels on HTTP headers at every hop, and Lambda reads it from context.client_context.custom . 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. The identity context stays inside a single Lambda invocation: It’s derived from the id_token , used immediately in an AssumeRole call, and discarded. It doesn’t go back to the agent, the gateway, or the UI. Authorization decisions live in Lake Formation, against the real user only: The 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. The audit trail requires no extra work: The CloudTrail AssumeRole event with onBehalfOf identifies the human user for every query. You get the same audit fidelity you would have for human users accessing data directly. Deploy the pattern To deploy this pattern, you need to configure four things: An OIDC IdP with a TTI in IAM Identity Center accepting its tokens, and an Identity Center OAuth Application configured for CreateTokenWithIAM . Bedrock AgentCore Runtime running your agent container with requestHeaderAllowlist covering Authorization and your custom id_token header. Bedrock AgentCore Gateway with a Lambda target whose metadataConfiguration.allowedRequestHeaders includes the id_token header. The Lambda target’s tool schema has no id_token parameter. Lambda reading the id_token from context.client_context.custom[‘bedrockAgentCorePropagatedHeaders’] , performing the token exchange through sso-oidc:CreateTokenWithIAM , and calling sts:AssumeRole with ProvidedContexts to get the TIP-bearing session. Conclusion When 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. The three Bedrock AgentCore features that make this composable ( requestHeaderAllowlist on runtime, metadataConfiguration.allowedRequestHeaders on gateway, and bedrockAgentCorePropagatedHeaders on Lambda) are specific to building on Bedrock AgentCore. Everything downstream of Lambda is IAM Identity Center and Lake Formation functionality. If 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. The 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. Related resources Trusted Identity Propagation with AWS IAM Identity Center AWS Lake Formation User Guide Amazon Bedrock AgentCore Runtime custom headers Amazon Bedrock AgentCore Gateway header propagation RFC 7523 – JWT Bearer Profiles for OAuth 2.0 Amazon Bedrock AgentCore Runtime A2A protocol contract If you have feedback about this post, submit comments in the Comments section below. Thiyagarajan Mani Thiyagarajan 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. Mihir Borkar Mihir 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. Philippe Duplessis-Guindon Philippe 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. Umang Khambhalikar Umang 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. TAGS: AWS IAM Identity Center , AWS Lake Formation , Security Blog Loading comments…

Managed Apache Iceberg at scale: How Spanner powers Lakehouse runtime catalog

Google Cloud · Agent 身份 · 2026-10-07T00:00:00+08:00 · AI Agent · 已采集

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

来源摘录和自动提取正文均不等于人工核验。

自动提取的正文

Data Analytics Managed Apache Iceberg at scale: How Spanner powers Lakehouse runtime catalog October 7, 2026 Vinod Ramachandran Product Manager Mina Mikhail Software Engineering Manager Try Gemini Enterprise today The front door to AI in the workplace Try now 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 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. In 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 Lakehouse runtime catalog can help address them. Powered by Spanner , 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. Challenges a managed catalog needs to solve in the Lakehouse When 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: Atomic commits and concurrency control: Iceberg 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. High availability and operational maintenance: Because queries fail immediately if the catalog is down, a managed catalog becomes a critical Tier-1 service. Scaling the database backing the catalog: Catalog 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. Table maintenance coordination: A catalog alone does not optimize data; you must build and operate ancillary pipelines for compaction, snapshot expiration, manifest rewriting, and orphan file cleanup. Governance and security: A catalog acts as the security gatekeeper. The catalog must implement and maintain: Authentication protocols (e.g., OAuth2 token exchange, IAM federation) Access control down to namespace and table levels Vended storage credentials (e.g., generating short-lived tokens so query engines don't need broad, direct storage credentials) Lakehouse runtime catalog To 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 Apache Iceberg. By natively implementing the Apache Iceberg REST Catalog specification , the 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, Etsy migrated its catalog to Lakehouse runtime catalog, joining data in place to accelerate pipeline queries by 60%. This approach offers a number of architectural benefits: Open APIs : Support for Iceberg Rest Catalog enables different teams to use their preferred analytics tools on a single, unified dataset. Multi-engine interoperability : 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. Read/write interoperability for Iceberg tables: Leverage 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. Fully managed Iceberg storage with enterprise-grade features: Use Google's differentiated infrastructure to run analytics with performance on Iceberg tables. This gives you the benefits of open-source flexibility plus performance, scale, governance, and multimodal processing. Zero data copy : Table definitions point directly to your existing data in the underlying object store. You do not move, rewrite, or duplicate your underlying data. Bi-directional catalog federation across clouds: Access data from Databricks Unity , Snowflake Horizon and AWS Glue with support for vended credentials and OIDC token exchange. This lets you bring Google AI directly to your AWS and Azure data . Secure access using credential vending : The catalog supports multiple authorization mechanisms, letting you choose between credential vending and 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). AI-powered context and governance: The Lakehouse runtime catalog integrates directly with Knowledge Catalog and Cloud IAM , allowing you to define trusted context for your agents, and apply table-level security consistently across all compute engines. Get out-of-the-box search, lineage, and insights for Iceberg tables in the catalog. Atomic commits and concurrency control, high availability and scalability: Backed 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. What powers the Lakehouse runtime catalog? The Lakehouse runtime catalog is a highly available, concurrent and scalable catalog with strong consistency guarantees because it is built on top of Spanner . 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. Spanner makes the Lakehouse runtime catalog highly available through Spanner’s regional configurations with 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 traditional trade-offs between relational consistency and distributed scalability, delivering Lakehouse runtime catalog’s industry-leading consistency guarantees . 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. This foundation allows Lakehouse users to operate at agent-scale. Then, 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 full-text search and native vector search provided 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. Combine analytical and operational workloads With 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. Below, 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. Find out most congested traffic routes in Manhattan Modernize to the borderless Lakehouse Modernizing to Google Cloud’s Lakehouse minimizes 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 runtime catalog helps prepare your modern cloud environments to operate at agent-scale. To learn more and get started with a free trial, visit the Lakehouse web page and learn more about Spanner here . Posted in Data Analytics Databases Related articles Data Analytics Accelerating analytics: PayPal’s journey with Managed Service for Apache Spark By Vinod Ganesan • 3-minute read AI & Machine Learning Empower your agents with the Google Cloud CLI remote MCP server By Prosper Nwankpa • 6-minute read Data Analytics Introducing Ask, a new Google Earth Engine feature to accelerate geospatial coding By Joel Conkling • 4-minute read Data Analytics Maximizing Apache Spark availability: Mitigating compute stockouts with flexible VMs and other best practices By Sravani Bobbala • 8-minute read

OpenID Foundation · 2026-10-06T20:09:04+08:00 · 身份认证 · 已采集

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 .

来源摘录和自动提取正文均不等于人工核验。

自动提取的正文

Call for proposals: sharing lessons on adoption and scale Published October 6, 2026 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 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. The OpenID Well-Known Conference , taking place February 2–4 2027 in London, aims to do just that. The conference will bring together ecosystem leaders, practitioners, and standards experts in order to learn from each other. To 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. Elizabeth 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.” The guidance below is intended to help speakers shape their submissions. Proposals that help others learn Each 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. Strong proposals also: Offer lessons another ecosystem or jurisdiction could apply. Explain how an ecosystem got to where it is, not only what it built. Share what did not work, as well as what did. Consider relying parties and credential holders, not only issuers. Focus on experience and insight, rather than products or services. Link AI and identity topics clearly to adoption or scale. How to submit The proposals can be submitted here . Tickets are already available and can be booked through Eventbrite here . Members interested in sponsorship can review the Sponsor Prospectus . About the OpenID Foundation The 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. Tagged Adoption Call for Proposals digital credentials Digital Identity ecosystems Interoperability OpenID Well-Known Conference

Networking for AI inference model serving - GKE only and for all other backends

Google Cloud · Agent 身份 · 2026-10-06T20:00:00+08:00 · AI Agent · 已采集

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

来源摘录和自动提取正文均不等于人工核验。

自动提取的正文

Developers & Practitioners Networking for AI inference model serving - GKE only and for all other backends October 7, 2026 Ammett Williams Developer Relations Engineer 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 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. Both 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. Common services in the designs Both reference designs use these services: Private Service Connect inference endpoint : Anchors the entry point inside your consumer Virtual Private Cloud (VPC) network. Traffic hits a private internal IP address , keeping inference calls in your private network. Apigee API Management (Optional) : Integrates via an Apigee Extension Processor callout to handle client identity verification, rate limits, and quota enforcement before requests ever reach compute resources. Model Armor : Serves as an inline AI safety checkpoint, screening prompts and output completions against prompt injection and sensitive data leakage. Design pattern serving on GKE only This section focuses on a GKE-only backend design. To understand the full end-to-end concept, please read the entire architecture document Networking for AI inference model serving on GKE . The design pattern is based on this diagram: In addition to the common services identified in the previous section, the design for GKE uses these components: GKE Inference Gateway : Deployed as an internal Application Load Balancer ( gke-l7-rilb ). It acts as a specialized ingress engine that parses incoming request payloads, evaluates HTTPRoute rules, and steers queries to appropriate model-serving targets. Inference pools : 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. Model replica sets : 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. The traffic flow GKE example A client application that uses this GKE-based architecture to call a backend model would go through a flow like this: Ingress : 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. Payload inspection : The Gateway reads the target model parameter specified in the request body and adds it to the HTTP headers. Control plane validation : If Apigee is used, it checks client credentials and quotas. Model Armor screens the prompt for policy violations or data leakage. Backend selection : 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. Egress : The replica runs the inference workload. Output tokens pass through Model Armor for final response verification before streaming back over the private connection. Design pattern serving on all backends This section focuses on multiple backend types which can be used for inference, and it provides an overview of the architecture in the following diagram. To understand the full end-to-end concept, please read the entire architecture document Networking for AI inference model serving on all backends . For architectures spanning mixed environments such as GKE, Cloud Run, Agent Platform, on-premises data centers, or external clouds, these additional components are used: Regional internal Application Load Balancer : Serves as the central Layer 7 routing proxy that manages routing logic, SSL termination, and Service Extensions callouts. Inference Payload Processor (Service Extensions) : 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. A 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. Network Endpoint Group (NEG) : Delivers flexible routing to heterogeneous backends based on the injected model header. All-backends traffic flow example A client application that uses this architecture to call a backend model would go through a flow like this: Private ingress : The client application targets the Private Service Connect endpoint over private IP address space. The regional internal Application Load Balancer receives the request. Model name extraction : 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. Policy and safety enforcement : The request passes to Apigee for identity and quota validation, then to Model Armor to scrub sensitive data and block malicious prompts. NEG routing : 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). Private delivery : The target backend executes the model prompt, Model Armor screens the completion, and the result returns privately along the ingress path. What's next Take a deeper dive into building AI workloads on Google Cloud: Document set: Agentic AI architecture guides Architecture Center: Multi-agent private networking patterns in Google Cloud Document: Gemini Enterprise Agent Platform networking access overview Want to ask a question, find out more, or share a thought? Please connect with me on Linkedin . Posted in Developers & Practitioners Networking Related articles Developers & Practitioners Announcing MCP Toolbox Java SDK v1.0: Agentic data access for the enterprise By Abirami Sukumaran • 8-minute read Containers & Kubernetes GKE CPU startup boost: Accelerate app starts without over-provisioning By Abdel Sghiouar • 6-minute read Developers & Practitioners Democratizing Managed Lustre with lower cost and frictionless development By Barak Epstein • 6-minute read Developers & Practitioners Introducing the Server Side Cloud Swift SDK By Karl Weinmeister • 6-minute read

来源采集状态

FIDO Alliance：成功，相关 0 条，无发布日期跳过 0 条
OpenID Foundation：成功，相关 1 条，无发布日期跳过 0 条
Microsoft Security：成功，相关 0 条，无发布日期跳过 0 条
IETF Blog：成功，相关 0 条，无发布日期跳过 0 条
Auth0 · AI Agent 身份：成功，相关 0 条，无发布日期跳过 0 条
WorkOS · AI Agent 身份：成功，相关 0 条，无发布日期跳过 0 条
AWS Security：成功，相关 2 条，无发布日期跳过 0 条
AWS AI · Agent 身份：成功，相关 0 条，无发布日期跳过 0 条
Google Cloud · Agent 身份：成功，相关 3 条，无发布日期跳过 0 条
Cloudflare · Agent 身份：成功，相关 0 条，无发布日期跳过 0 条
GitHub Security · Agent 身份：成功，相关 0 条，无发布日期跳过 0 条
GitHub Changelog · Agent 身份：成功，相关 0 条，无发布日期跳过 0 条
SPIFFE / SPIRE：成功，相关 0 条，无发布日期跳过 0 条

身份认证日报 · 2026-10-07 ​

Announcing MCP Toolbox Java SDK v1.0: Agentic data access for the enterprise ​

自动提取的正文 ​

Improving SPIRE security and resiliency with AWS managed services ​

自动提取的正文 ​

Identity-aware AI data agents with AWS Lake Formation and Trusted Identity Propagation ​

自动提取的正文 ​

.bedrock_agentcore.yaml ​

Managed Apache Iceberg at scale: How Spanner powers Lakehouse runtime catalog ​

自动提取的正文 ​

Call for proposals: sharing lessons on adoption and scale ​

自动提取的正文 ​

Networking for AI inference model serving - GKE only and for all other backends ​

自动提取的正文 ​

来源采集状态 ​

身份认证日报 · 2026-10-07

Announcing MCP Toolbox Java SDK v1.0: Agentic data access for the enterprise

自动提取的正文

Improving SPIRE security and resiliency with AWS managed services

自动提取的正文

Identity-aware AI data agents with AWS Lake Formation and Trusted Identity Propagation

自动提取的正文

.bedrock_agentcore.yaml

Managed Apache Iceberg at scale: How Spanner powers Lakehouse runtime catalog

自动提取的正文

Call for proposals: sharing lessons on adoption and scale

自动提取的正文

Networking for AI inference model serving - GKE only and for all other backends

自动提取的正文

来源采集状态