Inside GitHub’s new Git storage architecture

Post Syndicated from Karthik Raman original https://github.blog/engineering/architecture-optimization/inside-githubs-new-git-storage-architecture/

Last week at GitHub Universe, we announced our new Git storage architecture, capable of handling thousands of writes per second with reads that scale on demand. Through internal testing, we’ve demonstrated the ability to support 5,000 concurrent agents working on a repository, sending 7,200 pushes per second to a repo, all while serving read traffic with consistently low latency. This new architecture is the foundation for GitHub to support agentic development for hundreds of millions of developers, and we’ve been building it underneath GitHub while it keeps running.

Over the past year, agents changed what a busy repository looks like on GitHub. In our first post in this series, we laid out the two principles behind our next-generation Git storage architecture: minimize coordination, and decouple storage from compute. In our last post, we covered the bridge: moving 99.99999% of repositories into Azure, scoping the write quorum to individual references, and standing up virtual replicas backed by Azure Blob Storage.

We also left off with an observation: very little of a write needs to be ordered. Git objects are immutable and named by their contents, meaning two writers can store them at the same time without agreeing on anything. The part of a push that needs agreement is the reference update, and a reference update is tiny in comparison. Virtual replicas were the first step toward building around that, and the means by which we onboard repositories to the new architecture.

The rest of the architecture builds on that observation. Only reference updates need agreement. That lets the parts of Git infrastructure that used to be tightly coupled (storing data, serving requests, and maintaining repositories) scale independently. For developers, Git stays Git: they push, fetch, and branch the same way, with the same protections in place. Below, we walk through the requirements behind the design, follow a request through the system, and dive deep into two of its components.

Building for agent scale

We think about the scale of the GitHub platform along two axes:

  1. Horizontal scale is how many developers and agents can work across many repositories. Many of GitHub’s current approaches on this axis have been battle-tested over the years and are carried forward to the new architecture: partitioning of tenants across infrastructure, isolation and/or fairness enforcement of tenant traffic, and load-aware routing, to name a few.
  2. Vertical scale is how many developers and agents can work on one repository. As agents write more code, we expect individual repositories to get larger and busier, so most of our requirements came from the vertical axis.

Today, the busiest repositories on GitHub.com receive at most dozens of writes in a single second, typically in short bursts. As more of that work shifts to agents running in parallel and around the clock, we expect those bursts to become a sustained rate within the next year. Each push leads to more reads: CI runs, deployment systems pull the new commit, and other agents fetch it for context. This read fan-out results in a large amplification effect on overall traffic that scales with writes.

We’re already seeing this trend play out on repositories at the top of the curve. The chart below shows daily requests to one repository on GitHub from March to May, when its traffic grew about 4x. Its growth has continued on an exponential trajectory since then.

Line chart of daily requests to a single repository from March through May 2026. The March average is 44M requests per day and the May average is 181M requests per day, about a 4x increase.

We have to plan for a world where agent-driven development keeps accelerating at this speed. Instead of planning for the next increment, we set a target of at least two orders of magnitude more scale. For a single repository, that meant the new architecture needed to:

  • Accept thousands of writes per second.
  • Support multiple writer nodes. There are two reasons for this:
    • Experience has taught us that indexing incoming packs and checking object connectivity are the most CPU-expensive parts of a write, and that cost scales with the size of the write, so a single node will become compute-bound quickly.
    • Spreading that work across many nodes improves fault tolerance and shortens recovery when a node fails.
  • Minimize commit latency. An agent waits on each push before it moves to its next step.
  • Record changes in order for each reference with the ability to quickly linearize across references. A virtual replica that falls behind needs to catch up by downloading only the data it needs to serve the incoming request.
  • Keep reads cheap when nothing has changed, which is the common case given the read-to-write ratio.
  • Let each component scale independently.

On top of that, the system had to be able to improve overall reliability and scale globally.

Introducing “Project Rubicon”

In May of 2026, hot on the heels of the initial Azure migration, we started working on a design that could meet those demands. We tried several approaches. In all of them, pack data lived in Azure Blob Storage, and in some we experimented with keeping reference state there too. We’ll cover some of the trade-offs we found below, but we settled on a design we felt maximized throughput while preserving the correctness, durability, availability, and latency guarantees a platform like GitHub requires. We called it “Rubicon,” a nod to the point of no return the industry crossed with agentic development.

Let’s walk through Rubicon from the top down. Many things stay the same: requests from Git clients, the API, and the web UI arrive at Spokes, which still handles routing and load balancing, and serves the internal API that the rest of GitHub uses to read and write repository data. Spokes also maintains its role as a placement and balancing service, maintaining the partitioning, isolation, and tenant fairness required for horizontal scale. The data plane underneath Spokes, in contrast, is new.

Architecture diagram. Git, API, and Web requests pass through Spokes to groups of virtual replicas per repository. Virtual replicas hold only cached state. Ref-CAS stores refs and the pack manifest, and Azure Blob Storage stores pack data. Compaction nodes compact and garbage collect packs in Blob Storage and update the pack manifest in Ref-CAS.

Spokes routes each request to one of a small group of virtual replicas assigned to that repository. Virtual replicas are a single fleet of disposable compute that serves reads, writes, or both. A virtual replica’s local disk is a cache that can be rebuilt at any time.

Spokes routes a repository’s traffic to the same virtual replicas when it can, which keeps their caches warm and latency low, but nothing about correctness depends on a request landing on any particular virtual replica. When a virtual replica goes away, the repository’s other virtual replicas keep serving, and a replacement fills its cache as traffic arrives.

When a repository gets busy, we add more virtual replicas. Separately, a fleet of compaction nodes works in the background, directly against Blob Storage and Ref-CAS, to merge each repository’s packs and remove unreachable objects. That work never runs on a virtual replica, meaning their CPU and memory can be almost entirely dedicated to serving requests.

Durable state lives in two places:

  1. Git objects, in the form of packs and auxiliary read acceleration data, live in Azure Blob Storage.
  2. References and the list of packs that make up the repository (the pack manifest) live in a separate replicated log service we call Ref-CAS (for “Reference Compare-and-Swap”).

Let’s walk the architecture from the perspective of a write and a read:

  • Write: a virtual replica indexes the incoming pack and uploads it to Blob Storage, then commits one transaction to Ref-CAS that lists the pack in the manifest and updates the references. Later, a compaction node merges that pack with others to keep reads fast.
  • Read: a virtual replica checks its reference version with Ref-CAS, pulls the packs it needs from Blob Storage into its cache, and serves the read from there.

There are many distinct approaches we’ve taken within the new architecture, from the software stack on the virtual replicas to how traffic routing and workload scheduling are tuned for different use cases (e.g., many small repos vs. one large one). Let’s dive deep into two components of the architecture and tell their stories centered on the two design principles.

Minimizing coordination: mutating reference state at high throughput

Object storage services like Azure Blob Storage are incredibly good at what they do, and natural fits for many data-heavy applications like source code storage. They are durable and replicated, hold as much as we need them to, have a relatively low cost per byte, and deliver exceptionally high aggregate throughput so long as traffic is spread across many keys. As a result, nearly everything durable in the new Git storage architecture lives in Azure Blob Storage, including:

  • Packs and indexes written by pushes, compaction, and garbage collection.
  • Various read accelerators (like multi-pack indexes, reachability bitmaps, and some custom formats) that our maintenance process builds from those packs.
  • Records that let compaction and garbage collection resume or audit their work, along with the leases that compaction nodes use to claim work.
  • Cached responses for frequently repeated fetches.
  • Checkpoints for the reference state of the repository, though not the authoritative state used to serve requests.
Diagram of one repository's data in Azure Blob Storage. Push, Compaction, Maintenance, GC, and Ref-CAS write into it, and fetches read from it by exact key. It holds packs and indexes, records and leases, read accelerators such as the multi-pack index and reachability bitmap, cached fetch responses, and reference checkpoints.

Most of that data is written once to a distinct key and never changes afterward, which is what makes it highly suitable for Blob Storage.

References are the opposite. A busy repository’s references are a relatively small piece of state that many writes race to update at the same time. That access pattern is harder to serve from Blob Storage, and our first prototypes showed us why. Object storage for this kind of workload is an intuitive choice, and one that works well up to a certain level of scale: conditional writes give a compare-and-swap for free, and the data is already durable and replicated. However, we ran into a difficult set of choices, illustrated below by two approaches we tried.

Our first approach was a write-ahead log for all of a repository’s references, indexed by a single blob. Every update is a conditional write against that blob. It’s correct, and reads are cheap: a virtual replica asks whether the blob has changed, and if it hasn’t, it’s done. Writes are where it falls short. Only one conditional write to a blob can be in flight at a time, so even when we batch every push that arrives during a write into the next one, the repository’s write ceiling is one write per round trip to a single blob. In practice, this netted us write throughput in the mid-hundreds per second.

Our second approach split the references across several segment blobs, with each reference hashing to one of them. Writes to references in different segments no longer wait on each other, which raises the ceiling. But a read now has to check every segment to know whether anything changed, and it’s only as fast as the slowest segment. We’d traded write latency for read latency, and reads outnumber writes by orders of magnitude. We can visualize this by showing multiple writes and a read side by side:

Neither option met every requirement, so we built something else: a replicated log service dedicated to references, or the Ref-CAS service. This is the (small) consensus group we said at the end of the last post was still somewhere in the stack. Here’s how it works.

Each reference update in Ref-CAS is a compare-and-swap committed by a quorum. A transaction locks only the references it touches, checks that each one still has the value the writer expects, and becomes visible once a majority of the log’s replicas have recorded it. Agents mostly push to their own branches, so most updates don’t contend, and they replicate in parallel. When two pushes do update the same reference, only one will append to the log.

Each commit to Ref-CAS gets a log sequence number (LSN), and the repository’s version is the LSN of its latest commit. Reads start with a version check against that version. A virtual replica sends the version of the reference state it already holds. If that version is still current, the reply carries no references at all, and an unchanged repository costs a single comparison. If the virtual replica is behind, it gets back the current references and version, along with pointers to pack data and anything else that needs to be known, such as when the last garbage collection cycle occurred.

Unlike the consensus group in our legacy architecture, Ref-CAS never holds or validates object data. It only stores pointers to it. A virtual replica uploads a push’s pack to Blob Storage before it commits the reference transaction. A reference only ever points at objects that are already durable.

These approaches allow us to transact reference state alone in the tens of thousands of operations per second, and provide a baseline for additional annotations on the replication log that help reads decide what to download for a given request.

But supporting thousands of writes per second on a single repository creates a second-order problem: maintaining the performance of reads and writes. For that, we needed a different approach to compaction.

Decoupling storage from compute: compaction at thousands of writes per second

Every push adds a pack to Blob Storage. Git can serve a repository from many packs, but each additional pack makes lookups slightly more expensive, so the pack count can’t grow without bound. In our legacy architecture, compaction runs on the same replicas that serve traffic, and it has to run on every replica. In the new architecture, it runs entirely in the background on separate nodes, directly against durable storage, using the Ref-CAS service to notify virtual replicas of the evolving state.

Compaction nodes each claim ownership over a subset of the repository’s data via a lease, which allows us to scale compaction horizontally. Here’s how one compaction node works through a single shard of a repository’s packs:

The node first takes a lease on the shard in Blob Storage, so only one node compacts a shard at a time. Meanwhile, virtual replicas keep uploading packs and listing them in the pack manifest. The node reads the manifest to find new packs and collects them into an open segment, which is effectively a holding ground for data about to be compacted. When the segment reaches a defined limit based on pack count, size, or age, it seals the segment so it accepts no new packs, then combines its packs into fewer, larger ones. While compaction happens, the next segment for the shard can begin capturing its input packs. Before anything is published, the node checks that the new packs contain exactly the same objects as the inputs. It then uploads the new packs and adds them to the manifest. A second transaction removes the inputs from the manifest, and cleanup deletes them later.

To scale out, this process runs independently for many shards at once. Each pack’s hash maps to a shard, so adding shards and nodes adds compaction throughput. A compacted pack that’s still under the size limit goes back into a shard by its own hash and merges again, so packs grow in tiers until they reach the limit. The net result is an effectively flat pack count while pushes climb:

Compaction merges packs, but it keeps every object. Garbage collection is the step that removes objects nothing references anymore, like the ones left behind by deleted branches and force-pushes. In our new architecture, garbage collection works very similarly to compaction by using dedicated workers to handle the compute-heavy portion. It also has a few special behaviors for safely removing data, which are worthy of their own discussion.

Using these approaches, we’ve been able to consistently demonstrate a flat latency curve as writes climb, and we have other planned optimizations to make the compaction and garbage collection processes themselves more performant.

What comes next

The two principles we started with let each part of this architecture scale on its own. We scale reads and writes by adding virtual replicas. Ref-CAS orders each reference independently instead of the whole repository. We scale maintenance by adding compaction nodes. Our goal is for every repository, from one developer’s side project to the busiest monorepo, to run on the same architecture with no special handling for the busy ones. Repositories don’t stay small. A side project can pick up a fleet of agents overnight, and it shouldn’t need a migration or special handling from us to keep up. One architecture also means every improvement we make reaches every repository at once.

This foundation lets us do a lot more. We’re focused on three areas next: scaling the architecture beyond what we can predict we’ll need today, making agents more efficient at the work they do on GitHub, and evolving Git itself for agentic development.

Improving the architecture

We have plans to take this architecture further. Each of these improvements lets a repository handle more activity while reducing the work behind each request:

  • Read only what’s needed. Fetch a single object from Blob Storage instead of the whole pack that holds it.
  • Organize packs by type. Group commits, trees, and blobs into their own packs. Many requests then touch less data.
  • Partial replicas. Serve requests without every pack on local disk.
  • Materialized views. Keep repository data in ready-to-use forms, like prepared archives, a near-live shallow copy of the default branch, and agent session context stored alongside each commit.
  • Global replicas. Place replicas in any region, close to the workloads that use them. Reads stay within bounded staleness of the latest write.
  • Scale to zero. Grow and shrink the fleet with the repositories that are actually active.

Efficient agent operations on GitHub

Scaling the infrastructure is one side of supporting agents. The other side is making each agent operation cheaper: fewer bytes to fetch, fewer round trips, and less waiting on changes. Each of these fast-follow items builds on the storage work in this post:

  • Work without a clone. Many agent tasks never need a full working tree. They need a handful of files and enough context to make a change. They can read both straight from the server.
  • Atomic commit API. Land a multi-file change in one operation. The whole change commits, or it’s rejected cleanly on conflict.
  • Event streams. Agents and the systems around them work best with real-time information. A generic event stream lets them subscribe to changes and react as they happen.

Improving Git for agents

We also have work to do in Git itself. GitHub has been a longtime contributor to the Git project, and we’re not stopping now. A few examples of the work we’re excited to continue:

  • Lightweight clones. Partial clone, shallow clone, and sparse checkout each let an agent fetch less. Each one has gaps. They don’t always work well together, either. We want to improve each piece and make them fit.
  • Remove hidden scaling costs. Git still has code paths that slow down much faster than the repository grows. Recent releases fixed several of them, but we expect to find more.
  • Faster history walks. Metadata like the commit-graph can answer merge-base and reachability questions without walking every commit. That matters most when an agent’s API call turns into Git work on the server.
  • Avoid common gotchas. Agents make the same mistakes developers do. Git can catch more of the common ones and warn before they cause damage.

Agents have changed how software gets built. GitHub and Git are changing with it. We’re excited to take this new architecture across the starting line. It’s available in a limited private preview now, with a broader rollout early next year. We can’t wait to see what teams build when the number of agents working on a repository is limited by their ideas. We’ll keep evolving Git and GitHub alongside our customers and the Git community.

The post Inside GitHub’s new Git storage architecture appeared first on The GitHub Blog.

Introducing AWS account access manager: IAM role flexibility with centralized workforce access

Post Syndicated from Moumita Saha original https://aws.amazon.com/blogs/security/introducing-aws-account-access-manager-iam-role-flexibility-with-centralized-workforce-access/

AWS Identity and Access Management (IAM) is introducing account access manager, a flexible new way to manage workforce access to your Amazon Web Services (AWS) accounts. This combines the IAM role flexibility your teams already rely on, delivered through the centralized federation of AWS IAM Identity Center, with user-level visibility built-in.

Account access manager streamlines the assignment of your existing IAM roles from individual AWS accounts to your workforce users and groups in an organization instance of IAM Identity Center, giving you a clear path to centralized access management at scale. You can adopt account access manager on its own or alongside IAM Identity Center permission sets; both draw on the same users and groups you already synchronize from your corporate identity provider. That means you assign your existing IAM roles to those users and groups directly, without duplicating identities or managing per-account federation points.

Why use account access manager?

Enterprises scaling on AWS have long faced a difficult choice in workforce access: the flexibility of IAM roles or the central control of IAM Identity Center. Until now, granting workforce access to AWS accounts generally meant choosing one of two approaches, each with trade-offs to consider. Federating into each account separately with IAM roles gives you the full flexibility of IAM roles—custom trust policies, tags, and paths—but requires you to configure an identity provider and manage role assignments independently in each account, making it harder to assign a group across multiple accounts or maintain a unified view of who has access where. Federating once through IAM Identity Center with permission sets gives you a single federation point with centrally provisioned, uniform access, but permission sets can feel restrictive for teams whose roles vary from account to account, or that have difficulty generalizing their existing roles into uniform sets.

Account access manager removes the trade-offs. It’s built for customers who want the single federation point and identity-propagation benefits of IAM Identity Center together with the flexibility of IAM roles. Because it uses the IAM roles you already own, you keep the tailoring capabilities you rely on today:

  • Attribute-based access control (ABAC) – Use IAM role tags, or session tags populated from your identity provider as SAML claims, for fine-grained, attribute-driven authorization.
  • Precise trust policies – Restrict role assumption with network conditions or identity provider (IdP)-asserted claims; such as group membership, department, or cost center, as trust-policy conditions.
  • Role paths for organization at scale – Use IAM role paths to group roles and simplify administration as your environment grows.

Because roles are managed in the account you provision access to, account access manager scales with your account usage rather than relying on Identity Center specific quotas. Assignments are made to users and groups, reducing administrative overhead, and providing accountability and auditability to the specific user and role being used.

How it works

Access flows through IAM Identity Center and carries the user’s identity through trusted identity propagation. Even when multiple users assume a shared IAM role, each role session contains user context that attributes every action to the individual user. Access is granted and audited against the actual user, so you can see who assumed which role in which account. The result is user-level visibility across your organization, not just at the point of sign-in. You also maintain access to the full set of IAM role capabilities, such as role paths, tagging, naming conventions, and other IAM primitives.

Figure 1: Account access manager connects IAM Identity Center federated workforce users and groups to AWS accounts specific IAM roles

Figure 1: Account access manager connects IAM Identity Center federated workforce users and groups to AWS accounts specific IAM roles

To grant a user access to a specific role in an account using account access manager, an administrator creates an entitlement. The user can then access that account from the new account access manager application portal or from their IAM Identity Center access portal, or retrieve credentials from the command line with aws login.

You can manage account access manager through the AWS Management Console for IAM and programmatically through the AWS Command Line Interface (AWS CLI) (aws login and the account-access API namespace), AWS SDKs, AWS CloudFormation, and HashiCorp Terraform and Pulumi, so you can enable it and manage role assignments the same way you manage the rest of your AWS infrastructure. It exposes its own API namespace, account-access, separate from the IAM API, with its own permissions and AWS CloudTrail events.

How to enable account access manager

Here’s how to enable account access manager in your own environment, from prerequisites through your first role assignment.

Prerequisites

  1. An organization instance of IAM Identity Center enabled.
  2. Users or groups in IAM Identity Center that you want to entitle with IAM roles from individual AWS accounts. If users or groups don’t exist already then either:
  3. IAM roles in the individual AWS accounts that you want to assign to users and groups of IAM Identity Center. If the role you need doesn’t exist, create a role using custom trust policies first.
  4. Appropriate permissions to enable account access manager and manage assignments (see the IAM policy examples later in this post).
  5. Both the organization instance of IAM Identity Center and account access manager must be enabled in your organization’s management account.
  6. For CLI access: Install or update to the latest version of the AWS command Line Interface (AWS CLI) v2.36.0 or newer.

Step 1: Enable account access manager

Before enabling account access manager, run the following command from the AWS organization management account to grant account access manager access to your organization:

aws organizations enable-aws-service-access --service-principal account-access.amazonaws.com

Next, use one of the following methods to enable account access manager:

Console:

  1. Sign in to your organization’s management account.
  2. In the AWS Management Console for IAM navigation pane, under Multi-account access, choose account access manager.
  3. The console Region should be set to the primary Region of your IAM Identity Center instance.
  4. If there is no organization instance of IAM Identity Center, you’ll be prompted to enable one before continuing. Otherwise, choose Enable account access manager.
Figure 2: Account access manager enablement from the IAM console

Figure 2: Account access manager enablement from the IAM console

AWS CLI:

Fetch the Amazon Resource Name (ARN) of your IAM Identity Center organization instance, confirm the Region code matches its primary Region, and run:

aws account-access create-application \
 	--region <Region> \
  	--identity-source '{
    		"identityCenter": {
      			"instanceArn": "<IAM Identity Center Instance ARN>"
    		}
 	}'

As an output, the account access manager application ARN will be generated.

After you enable account access manager (through the console or AWS CLI), you will get the account access URL and the account access manager ARN along with other details on the capability.

  • Account access portal URL is the single sign-on entry point for your workforce. This is where your users will go to access AWS accounts. Its format is - https://[Tenant-ID].account-access.[Region].app.aws , found on the Settings tab of the account access manager console).
  • Account access manager ARN: the identifier for the application instance created when you enable account access manager. Note this ARN to use in your IAM role’s trust policies so that only your specific account access manager application can assume those roles, providing confused-deputy protection (see Step 3 for details) and pass it as --application-arn when creating entitlements using the AWS CLI so each assignment is tied to the correct application instance.
Figure 3: Account access manager settings after enablement

Figure 3: Account access manager settings after enablement

In the AWS CLI, run the command aws account-access list-applications to get the application ARN and tenant-ID of the enabled account access manager instance ARN.

Step 2: Update firewalls and gateways

If you filter access to specific AWS domains or URL endpoints with a next-generation firewall (NGFW) or Secure Web Gateway (SWG), allowlist the account access portal domains and endpoints in the following list. Account access manager has no IPv4-only endpoints; endpoints are dual-stack.

  • Account access portal URL – https://[Tenant-ID].account-access.[Region].app.aws
  • Portal APIs – [Tenant-ID].account-access.[Region].app.aws/api/* and /auth/*
  • Control plane – account-access.[Region].api.aws
  • Runtime – account-access-runtime.[Region].api.aws
  • Console – console.aws.amazon.com/account-access

Step 3: Prepare your IAM roles

Before assigning IAM roles to users and groups, update the role’s trust policy to allow account access manager service to assume it.

Add the following statement to the role’s trust policy (or paste the entire policy that follows if you’re creating a new role). Replace <your-account-id>, <region> (your IAM Identity Center primary Region), and <application-id> (from the Settings page of the console).

Figure 4: Account access manager ARN details

Figure 4: Account access manager ARN details

IAM role trust policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AccountAccessManagerIAMRoleTrustPolicyStatement",
      "Effect": "Allow",
      "Principal": {
        "Service": "account-access.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetContext",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "<your-account-id>",
          "aws:SourceArn": "arn:aws:account-access:<region>:<your-account-id>:application/<application-id>"
        }
      }
    }
  ]
}

Define the Condition block to enforce confused-deputy protection. It helps ensure that the role can be assumed only by the specific account access manager application instance (defined using the application ARN) created when you enabled the service, and only when the request originates from your AWS account where that instance resides.

Best practice:

  • Propagate identity attributes with ABAC – The sts:TagSession action listed in the preceding IAM role trust policy allows upstream attributes from your identity provider (group memberships, department, cost center) to flow through as principal tags on the session. Without it, role assumption still succeeds; only session-tag propagation is suppressed. Add it when downstream IAM policies use aws:PrincipalTag/<key> and the tag is populated from your IdP SAML claims; leave it out otherwise.
  • Automate the trust-policy update – We recommend updating your IAM role-creation workflows to add this trust-policy statement automatically wherever it’s needed, so new roles are assignable from day one. You can use this sample-aam-migration tool as a reference.

Step 4: Assign access to users and groups

Like IAM Identity Center role entitlements, an entitlement in account access manager requires three components: a user or group ID, an account ID, and an IAM role ARN (instead of a permission set ARN). You can create assignments from the Accounts, Users, or Groups tabs in the console, or using the API or AWS CLI. For assignments where the same role needs to be assigned to multiple users, you must create each assignment individually. You can automate it using the account access API, the AWS SDK, or AWS CLI

Assign from the console:

  1. Choose the Users tab and search by username or display name.
  2. Select the user, then choose Assign new access.
    Figure 5: Assign new access in account access manager

    Figure 5: Assign new access in account access manager

  3. On the Assign account access page, enter the workforce user or group, account ID, and IAM role name, then choose Assign access.

Assign a user using AWS CLI:

aws account-access create-entitlement \
  --region <Region> \
  --application-arn "<Account_access_manager_ARN>" \
  --entitlement '{
    "principalRole": {
      "principal": {
        "identityCenter": {
          "userId": "<Identity_Center_User_ID>"
        }
      },
      "roleArn": "arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>"
    }
  }'

To assign a group, replace the userId block with "groupId": "<IDC_GROUP_ID>". To remove access, use aws account-access delete-entitlement with the entitlement ID.

Note:

  • The console can search users, groups, and accounts, but it can’t detect IAM roles because they can come from different AWS accounts in your organization; you must know the role name beforehand.
  • Only IAM roles whose trust policy grants account access manager as an allowed service principal are eligible for assignment.
  • IAM role sessions assigned by account access manager use the maximum session duration configured on the underlying IAM role in each AWS account, up to 12 hours.

Step 5: How workforce users can sign in

Workforce users can federate to AWS accounts using IAM roles assigned through account access manager in any of the following ways:

  1. Directly through the account access portal URL – Navigate to the portal URL (for example, https://aa-xxxxxxxxx.account-access.us-east-2.app.aws, or a vanity URL) and sign in.
  2. Through the AWS access portal – Go to the Applications tab, select the Account Access application, and you’ll be redirected to the account access portal, where your assigned accounts and their respective roles are listed.

Tip: We recommend that users bookmark both the account access portal and the AWS access portal for faster navigation. In addition, if you use a supported IdP, such as Okta, Microsoft Entra ID, or Ping Identity, you can add the account access portal as a bookmark app in the IdP’s dashboard; giving users authenticated, single-click access to the portal directly from the tools they already sign in to each day.

Access through a web browser

Use the following steps to use account access manager through a web browser.

  1. Navigate to the account access portal URL and sign in with your credentials.
  2. On the portal, find the AWS account you need. Search by account name or ID to filter the list of accounts you’re assigned to.
  3. Expand the account to see the roles you can assume.
  4. Select a role (for example, Developer). A new tab opens, signed into that account with the selected role.

Access through the AWS CLI

Account access manager works with the aws login command. To get started:

  1. Install the latest AWS CLI (v2.36.0 or newer).
  2. Sign in through your default browser – Sign in to your account access portal and into the target AWS account using one of your assigned roles.
  3. On the command line, run: 
    aws login

  4. Set a default Region if prompted – If you haven’t set one, the AWS CLI will prompt you for a Region (for example, us-east-2).
  5. Select your session – The AWS CLI opens a browser page; select the tile for the session you initiated.
  6. Confirm and return to the CLI – The page confirms that your credentials were shared successfully. Close the tab and keep working in the AWS CLI for the duration of your session.

The temporary credentials are automatically rotated by the AWS CLI, AWS Tools for PowerShell, and AWS SDKs, and remain valid for the default session duration of an IAM role. After the session expires, you’re prompted to sign in again on the browser.

Note: IAM Identity Center–specific commands, such as aws sso configure don’t work with account access manager assignments; use aws login instead. If you want to continue to use aws sso login, refer to AWS CLI Integration for IAM Account access manager.

Create shortcut links to specific console destinations

The portal also lets you create a shortcut link that opens a specific console destination for a given account and role. Shortcut links work only with accounts and roles already assigned to the user—they can’t grant new access—and URL parameters must be URL-encoded. Because shortcut links are Regional and expose the account ID and role name in plain text, review your organization’s sharing policies before experimenting with them.

Customer managed key considerations

If your IAM Identity Center instance is encrypted with an AWS KMS customer managed key, which is required when you replicate IAM Identity Center to additional Regions, check the key policy before you enable account access manager. We recommend implementing the current baseline KMS key policy to ensure account access manager can read user, group, and instance data from IAM Identity Center.

Best practices summary

  • Enable in the right place – Enable account access manager in your organization’s management account and in the same Region as your IAM Identity Center instance and confirm your organization instance is in place before you begin.
  • Automate trust-policy updates – Build the account access manager trust-policy statement into your role-creation pipelines so every new role is assignable from day one, with no manual intervention.
  • Add sts:TagSession only when you need it – Include it only where downstream policies consume principal tags; otherwise leave it off to keep sessions lean and least-privilege.
  • Assign roles to groups, not individual users – Granting access at the group level reduces administrative overhead and strengthens the auditability of user-level access.
  • Scope administrator permissions tightly – Separate managing the feature from managing assignments, and enable delegating administration to keep day-to-day operations out of the management account.
  • Allowlist the portal domains before rollout – Add the account access portal domains and endpoints to your next-generation firewall or Secure Web Gateway ahead of launch to avoid access disruptions.
  • Prepare your workforce users – Have users bookmark both the account access portal and the AWS access portal and communicate the aws login flow clearly to your developers.

Account access manager launch partners

Account access manager launches with a broad ecosystem of AWS identity and access-governance partners who have integrated the service into their existing solutions, making it available to our joint customers from day one. Leading identity providers Okta, PingIdentity and Cisco Duo extend account access manager so customers can manage human workforce access to AWS accounts directly from the identity platforms they already use. Alongside them, access-governance and privileged-access partners Apono, BeyondTrust, Britive, Sonrai Security, C1.ai and Lumos added capabilities to govern, provision, and audit that access through the tooling our customers already rely on.

Account access manager also integrates with leading infrastructure-as-code (IaC) partners, so teams can define and manage access assignments declaratively alongside the rest of their AWS infrastructure. Pulumi enables customers to codify account access manager role assignments as part of their existing provisioning workflows, bringing repeatable, version-controlled automation to workforce access at scale.

Conclusion

Account access manager combines the flexibility of the IAM roles your teams already own with the single, centralized federation point of IAM Identity Center, adding user-level visibility into what users or roles have done across your organization. You assign existing IAM roles to users and groups centrally, scale with your account usage rather than a fixed quota, and give developers a fast, secure command-line experience with aws login. It’s available at no additional cost, enabled by default in Commercial Regions (excluding opt-in Commercial Regions, GovCloud (US), China, and other non-commercial Regions).

To see account access manager in action, watch the enablement video, which walks through enabling the service, preparing your IAM roles, and assigning access to your workforce end to end. You can also extend account access manager through our launch partners; leading identity, access-governance, and IaC providers who have integrated the service into their platforms, so you can govern, provision, and automate workforce access to AWS using the tooling you already rely on. Review the preceding partner integrations to find the ones that fit your environment.

To learn more and get started, visit the AWS Identity and Access Management User Guide. We encourage you to enable account access manager in a test organization, assign your first entitlement, and explore how centralized, user-attributed access can simplify your AWS environment.

Moumita Saha

Moumita Saha

Moumita is a Sr. Identity Specialist Solutions Architect, currently driving identity innovation, she builds customer solutions, shapes product direction, and advances access management practices across industries. With over 14 years of security expertise, she has delivered high-impact security innovations for Fortune 500 enterprises and Global Systems Integrator partners.

Omar Zoma

Omar Zoma

Omar is a Principal Security Solutions Architect with AWS Industries. With 15 years of security experience spanning multiple industries, his goal is to help customers understand and improve their security and compliance posture in a scalable way. He tackles global security challenges through content creation, teaching, knowledge sharing, and contributing to global standards and organizational bodies.

How TUI scales threat modeling for 100+ teams with Amazon Bedrock

Post Syndicated from Vushesh Babu Adhikari original https://aws.amazon.com/blogs/architecture/how-tui-scales-threat-modeling-for-100-teams-with-amazon-bedrock/

When your security team has four engineers and your organization has over 100 digital product teams, threat modeling becomes a bottleneck fast. That was the challenge TUI faced. TUI operates across the travel and tourism industry with airlines, hotels, cruise ships, and local travel experiences. Our Platform & Engineering division needs security assessments to keep pace.

At TUI, each threat modeling session took 4–6 hours of manual work: reviewing architecture diagrams, mapping threats to internal standards, researching security issues, and documenting findings in Confluence. The team could complete only 3–4 sessions per month, leaving a constant backlog.

TUI needed threat modeling to become mandatory for every new service, not a luxury TUI reserved for the highest-priority projects. TUI built an AI-powered threat modeling system using Amazon Bedrock, collaborating with the AWS Generative AI Innovation Center during a 10-week proof of concept (PoC) to develop and validate the architecture. Amazon Bedrock is a fully managed service for building generative AI applications, and TUI used the Claude Sonnet 4.5 foundation model from Anthropic. TUI chose Amazon Bedrock for managed access to Claude Sonnet 4.5 without operating model infrastructure, its extended thinking support that the workflow uses for deeper analysis, and its integration with the AWS services already in TUI’s stack. TUI deployed the agentic workflow on Amazon Bedrock AgentCore runtime, part of Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale with any framework or model. AgentCore runtime hosts the agent in production without provisioning or scaling infrastructure. After the PoC, TUI took the system to production within 30 days.

In this post, we describe how TUI built an agentic AI workflow for threat modeling, the iteration process that shaped the architecture, and the results after deployment.

The challenge

TUI’s security engineering team followed a thorough but manual process: for each application, an engineer reviewed the architecture, identified threats using STRIDE methodology, mapped them to TUI Technology Standards, P&E-specific standards, and ISO 27001 controls, and documented findings in Confluence with Jira tickets.

With 100+ digital product teams and only 3–4 sessions possible per month, most teams waited weeks for their review. Security engineers also had varying levels of expertise across technology stacks, and there was no automated way to verify these standards were consistently applied to every assessment.

Solution overview

The solution extends AWS Threat Designer with TUI-specific capabilities through a serverless architecture deployed in the eu-central-1 (Frankfurt) AWS Region. Model availability varies by Region. For model availability by Region, refer to Supported models by AWS Region in Amazon Bedrock. Together, these services replace the manual review process with an automated workflow that applies TUI Technology Standards and P&E-specific standards consistently. The system uses the following key services:

  • Amazon Bedrock for threat analysis and generation using Claude Sonnet 4.5 from Anthropic, with configurable extended thinking budgets.

  • Amazon Bedrock AgentCore runtime for hosting the agentic workflow as a managed, serverless runtime. It runs the containerized LangGraph agent without provisioning or scaling infrastructure, supports long-running sessions that exceed typical function timeouts, and provides per-session isolation for concurrent threat models.

  • AWS Lambda for serverless backend compute with LangGraph workflow orchestration.

  • Amazon DynamoDB for workflow state management with resume capability.

  • Amazon Simple Storage Service (Amazon S3) for architecture diagram storage, TUI knowledge base, and web search cache.

  • AWS Amplify for the React front end with Amazon Cognito authentication.

TUI Threat Designer architecture diagram showing users authenticating through Amazon Cognito to a React front end on AWS Amplify, with requests flowing through Amazon API Gateway and AWS Lambda to an agentic workflow on Amazon Bedrock AgentCore that uses Amazon Bedrock, with Amazon DynamoDB and Amazon S3 for state and storage

Figure 1: TUI Threat Designer system architecture. Users authenticate through Amazon Cognito and interact with the React front end hosted on AWS Amplify. Requests flow through Amazon API Gateway to AWS Lambda, which orchestrates the LangGraph workflow through Amazon Bedrock AgentCore. The agent uses Amazon Bedrock (Claude Sonnet 4.5 from Anthropic) for threat analysis, with Amazon DynamoDB for state management and Amazon S3 for architecture diagram storage and caching.

The core is a LangGraph-based agentic workflow that processes architecture diagrams through several specialized nodes. Engineers upload one or more diagrams (for example, a high-level architecture alongside a detailed network topology), which the workflow converts to base64 to identify components and data flows. It then loads relevant security standards and generates threats with iterative refinement. The workflow runs gap analysis, optionally compares against a subject matter expert (SME) assessment, and assembles the final threat model with export options (PDF, JSON, or Confluence).

The following screenshot shows the submission wizard. Engineers provide a title, upload architecture diagrams, add optional context and assumptions, and select a reasoning depth based on architecture complexity. The entire setup takes approximately two minutes.

The Threat Designer submission wizard, showing fields for a title, architecture diagram upload, optional context and assumptions, and an iterations slider for reasoning depth

Figure 2: The submission wizard guides engineers through a six-step process. The iterations slider controls the reasoning budget, from None for quick scans to High for complex architectures with 20 or more components.

Once submitted, the system processes the architecture through each workflow node with real-time progress tracking. Engineers can monitor which phase is active and return to review results when processing completes.

Real-time progress tracking view showing the active workflow phase, with a Thinking indicator on the Threats node

Figure 3: Real-time progress tracking shows the current workflow phase. The Thinking indicator on the Threats node reflects the extended thinking capability of Claude analyzing the architecture against TUI security standards.

The iteration journey: from brute force to intelligent selection

TUI’s team didn’t arrive at the final design on day one. They iterated through several approaches, and each failure pointed toward the next improvement.

Attempt 1: Load everything into the prompt. The first approach loaded all 192 TUI security standards (338 KB) directly into the foundation model context. This failed immediately. Some individual standard documents run 20+ pages, and the combined content exceeded token limits before the foundation model could begin threat analysis.

Even with a subset of standards, the foundation model struggled to follow structured instructions. When asked to recommend only TUI-approved tools for mitigations, it would ignore the approved tool list and suggest generic alternatives. Too much contradictory information from different standards confused the model.

Attempt 2: Metadata-driven selection. The breakthrough came from treating the problem as a search and selection challenge rather than a prompt-loading exercise. Instead of loading all standards, the team pre-generated lightweight metadata for each document: keywords, component types, STRIDE categories, and a relevance score.

At runtime, the foundation model reviews this metadata (about 60 KB) and selects only the 16 most relevant standards for the specific architecture being analyzed. This reduced context from 338 KB to 21 KB, a 94% reduction, while maintaining coverage. The reduction is calculated from the metadata approach versus loading all standards directly.

The metadata approach fits the structure of TUI’s knowledge base: some documents are always mandatory (security guidelines, approved tools), while others apply only to certain architectures. The team also evaluated retrieval-augmented generation (RAG), but with a bounded corpus of 192 standards, some mandatory regardless of the query, metadata-driven selection proved more predictable and easier to debug. RAG may complement it as the knowledge base grows.

Agentic threat generation: a self-correcting workflow

The threat generation node is where the agentic behavior matters most. Rather than generating threats in a single pass, the system uses a Reason and Act pattern with a LangGraph subgraph. The agent has four tools at its disposal: adding threats, deleting threats, reading the current threat catalog, and running gap analysis.

The agent autonomously decides which tools to call and in what order. It generates an initial set of threats using STRIDE methodology, then reviews its own output against the loaded TUI standards. Each threat includes a title, description, affected component, and threat vector. It also assigns likelihood and impact scores using TUI’s risk matrix. Threats include recommended mitigations with TUI-approved tools and mapped ISO 27001 controls.

A tool budget system helps prevent the agent from generating indefinitely. After three threat-generation calls, the system forces a gap analysis. The agent must step back and assess what’s missing before generating more. This mimics how human security experts work: generate, review, identify gaps, fill them.

A validation node checks three conditions before the workflow can proceed: the threat catalog isn’t empty, all six STRIDE categories are covered, and gap analysis has been performed at least once. If a check fails, the agent receives specific feedback and loops back.

Based on TUI’s production data, the combination of iterative generation and gap analysis typically produces 40–60 threats per architecture, compared to the 30–40 that manual sessions identified. It also supports configurable extended thinking budgets, from 24K reasoning tokens for standard architectures up to 64K for complex systems.

Web search for current threat intelligence

Security threats evolve regularly. A threat model generated today needs to account for issues disclosed last week. The workflow integrates web search to fill gaps where TUI’s internal standards don’t cover specific technologies.

For every technology identified in the architecture (Keycloak, Kong, Redis, and so on), the system generates two search queries: one for known issues and one for hardening best practices. These queries target authoritative sources such as OWASP, NIST, and CWE databases. Before making an API call, it checks an Amazon S3-based cache with a 7-day time-to-live (TTL). Only technology component names are used for external searches. Architecture details and customer data are not included in queries.

The cache key uses a hash of the sorted component names, deliberately excluding foundation model-generated descriptions. Those descriptions vary slightly between runs even for the same diagram, which would reduce cache effectiveness.

Based on TUI’s monitoring data, the cache achieves a 70–80% hit rate because many TUI applications share core technologies. A cache hit returns results in under 100 milliseconds, compared to 2–3 seconds for a live search. TUI’s team evaluated multiple search providers during the PoC and designed the system with a pluggable provider architecture, allowing provider switching as capabilities evolve.

SME comparison: human-in-the-loop validation

TUI’s security engineers don’t just use the system. They validate it. The workflow includes an optional node where engineers upload their own manually created threat assessment as a PDF. The workflow extracts threats using Claude, normalizes risk ratings to a standard scale (LOW, MEDIUM, HIGH, CRITICAL), and matches them against the AI-generated threats using semantic similarity.

When the AI and the SME disagree on a threat’s severity, the system flags the discrepancy with both ratings and the SME’s rationale. For example, the AI might rate a credential stuffing event (automated login attempts using unintended disclosure of credential databases) as HIGH while the SME rates it MEDIUM. Over time, these comparisons calibrate the system’s risk scoring and surface areas where the AI consistently over- or under-estimates risk.

The following screenshot shows an SME Comparison Alert for a credential stuffing threat. The system matched the AI-generated threat with a similar SME threat, compared both ratings (AI: High, SME: HIGH), and provided the SME’s rationale alongside a recommendation.

An SME Comparison Alert for a credential stuffing threat, displaying the AI rating, the SME rating, the matched SME threat, the expert rationale, and a recommendation

Figure 4: An SME Comparison Alert for a credential stuffing threat. The system displays both the AI and SME ratings, the matched SME threat, the expert’s rationale, and a recommendation. In this case, ratings are consistent. When they disagree, the alert highlights the discrepancy for human review.

Path to production: 30 days from handover to live

After the PoC handover, TUI’s team took the system from prototype to production-ready deployment in 30 days. The following results reflect the system’s performance in production.

Results

Metric Before After
Time per assessment 4–6 hours Up to 70% reduction*
Sessions per month 3–4 10–12 (300% increase)*
Standards applied Varies by engineer 100% consistent
Threats identified 30–40 40–60 per architecture
Mandatory for all teams No (backlog too large) Yes (feasible at scale)

*Based on TUI’s internal measurements comparing pre- and post-deployment performance.

The solution processes each architecture in the eu-central-1 Region, with data encrypted at rest using AWS Key Management Service (AWS KMS) and in transit with TLS. Architecture diagrams and threat models are processed within the AWS infrastructure, helping TUI meet its data residency and security requirements.

The following screenshot shows the threat catalog, a card view of completed threat models. Each card displays the original architecture diagram, an AI-generated description, completion status, and threat counts by severity (red for high, yellow for medium, green for low).

The threat catalog card view of completed threat models, where each card shows the architecture diagram, an AI-generated summary, completion status, and threat counts by severity

Figure 5: The threat catalog provides an overview of completed threat models. Each card shows the architecture diagram, an AI-generated summary, and threat counts grouped by severity.

Engineers can select a threat model to view a dashboard with four analytical views: threats by likelihood, threats by STRIDE category, threats by target asset, and threat sources.

The insights dashboard for a completed threat model, showing 40 identified threats distributed across the six STRIDE categories and mapped to architecture components

Figure 6: The insights dashboard for a completed threat model. This example shows 40 identified threats (6 high, 24 medium, and 10 low) distributed across all six STRIDE categories and mapped to specific architecture components.

“In the first four weeks after launch, 64 users registered and 19 unique creators produced 34 threat models with Threat Designer. What previously took one to two weeks per assessment is now available on demand. As of October 2026, adoption has grown to 255 registered users, 86 threat models, and 43 active creators, demonstrating that teams are embracing self-service security as part of their development workflow.”

— Marvin Jordan, Head of Technology for Security Platform and Practices, TUI

Conclusion

TUI’s experience shows that agentic AI workflows can address a real operational challenge in enterprise security: making thorough threat modeling fast enough to be mandatory. The combination of metadata-driven context selection, self-correcting threat generation, and intelligent caching allowed a four-person security team to support over 100 digital product teams. TUI achieved consistent, standards-aligned assessments at scale.

Looking ahead, TUI plans to expand the system with automated Jira ticket creation for mitigation tracking and integration with CI/CD pipelines for pre-deployment security checks.

You can get started with Amazon Bedrock to build AI-powered security workflows and Amazon Bedrock AgentCore to deploy agentic applications in production. For hands-on guidance with your specific use case, connect with the AWS Generative AI Innovation Center. To explore the open source foundation that this solution extends, see the Threat Designer project on GitHub and the AWS blog post Accelerate threat modeling with generative AI.

We welcome your feedback and questions in the comments.

About the authors

Vushesh Babu Adhikari

Vushesh Babu Adhikari

Vushesh is a Technical Lead at the AWS Generative AI Innovation Center, where he builds AI-powered solutions for enterprise customers. He specializes in designing and delivering generative AI solutions, from fine-tuning and model customization to agentic workflows, helping enterprise customers move from proof of concept to production. Outside of work, he is a movie buff who enjoys badminton and road trips.

Tom Chester

Tom Chester

Tom is a Generative AI Strategist at the AWS Generative AI Innovation Center, helping customers identify and deliver high-impact generative AI use cases.

Satyam Saxena

Satyam Saxena

Satyam is an Applied Science Manager at the AWS Generative AI Innovation Center, where he leads teams building machine learning and generative AI solutions for enterprise customers.

Marvin Jordan

Marvin Jordan

Marvin is Head of Technology for Security Platform and Practices at TUI, where he leads cross-functional teams delivering secure software engineering, web application protection, and cloud security architecture. He drives secure-by-design thinking across TUI’s digital product organisation and beyond, influencing technical and strategic decisions that protect millions of TUI customers.

Joseph Thachil George

Joseph Thachil George

Joseph is a Security Engineer within the Security Practices team of the Product and Engagement domain at TUI. He leads AI-based security initiatives within the domain and supports product teams by providing secure, innovative, and effective security solutions.

Agents aren’t humans (but they kinda are)

Post Syndicated from Bryan Becker original https://blog.cloudflare.com/trusted-agent-delegation/

AI Agents now act on the web for millions of people. To a Site, an Agent can take many forms. It may be indistinguishable from a human user carrying out a task, or it might look like one visitor carrying many Users. This removes the ability for the Site to recognize, serve, and hold accountable the user or users behind the Agent, and causes the Site to face the costs when something goes wrong. This post argues that in order for Sites to maximize the access they provide to Agents, the ecosystem must develop new mechanisms to preserve the relationship between Sites and Users. Traditionally, in Security and Fraud Prevention, that requires three things: Identity, Reputation, and Accountability, allowing Sites to answer: Is the person acting being truthful about who they are? Is that person trustworthy? And who answers for the action?

“Personal AI Agents” (“Agents” for short) are automations that take instructions from a human (“User”) and pursue a goal by controlling a cloud computer or browser. They are usually hosted and maintained by an “Operator” as part of a managed service or consumer offering. Examples include Muse from Meta and dots from OpenAI, and more are launching all the time. Agents can potentially take any action online that their User could, without the limits that hold humans back. They don't tire, they run around the clock, they act in parallel, and they put up with friction no person would. Much of the web, from how Sites plan capacity to how they make money, assumes those limits.

Fundamentally, remotely hosted Agents are intermediaries. An intermediary is anything that sits between a User and a Site, so the Site sees it instead of the User. Agents are the newest kind of intermediary, but intermediaries have existed for a long time. Cloud browsers (hosted browsers that software controls on a User's behalf) and Proxies (services that relay a User's traffic, including VPNs) are intermediaries too. What has changed is the trajectory. Agentic traffic is growing rapidly and may eclipse traditional human browsing on the Internet in the near future. This forces a reckoning for anyone operating a Site today. Historically, a Site could simply block intermediary traffic and require Users to disable the intermediary service. That stops working when the majority of traffic is agentic. Once blocking is no longer viable, Site Operators are left with the problem that intermediaries have always created. The Site loses direct information about the User and must decide whether to trust the intermediary without it. 

This post covers Agents hosted somewhere other than the User's device. Local agents (e.g. OpenClaw) or Agents running in the User's own browser, on their own device, are out of scope of the primary topic addressed by this post (see below, "On open source and local Agents").

This post rests on one principle:

The Intermediation Principle: The business relationship between Users and Sites, and each participant’s security responsibilities, must be upheld regardless of intermediation.

A Site needs new tools to recognize, serve, and hold accountable a User acting through an Agent just as it could if that User had visited directly. The Agent, and the Operator behind it, must be recognizable and accountable too, because an Agent can do what no User could. Agents are able to scale human access almost without limit, so they create new risks, even for behavior that was previously benign.

The intermediary problem

Meet Ezra. Ezra works as a personal assistant for people in her city. Her best client is Amy, a local CEO, but she also works for Bob, Charlie, and Debra. She runs their errands: groceries, appointments, paperwork, and flights. Ezra blends into the crowd.

The corner grocer used to know Amy. He knew what she bought and set aside what he thought she'd like. Now only Ezra comes in, carrying orders for four people, and the grocer can't tell whose preferences are whose. He doesn't want to turn Ezra away, because she brings him a lot of business.

Then Bob asks Ezra to buy him an iPhone. A week later he calls the store, says he never authorized the charge, and keeps the phone. To win the dispute, the store has to prove Bob asked for it. But the only person the store ever saw was Ezra.

Then Charlie gives Ezra a list of passwords: "I forgot mine, but it's one of these." Ezra patiently tries each one at Charlie's bank. The bank can see an attack happening, but the only person it can ban is Ezra. Banning Ezra also bans Amy, Bob, and Debra.

None of these business owners has a problem with Ezra herself. Their problem is that they can only see Ezra, not the person she's acting for. Swap Ezra for an AI Agent and the businesses for websites, and you have the web today.

A website owner wants sufficient visibility both to prevent bad behavior and to effectively monetize or get value from their Site. But as with Ezra, much of that visibility goes away with AI Agents. Below is a list of actions that a website owner might want to address that were previously solved, but are made more challenging by allowing Agents.

In nearly every challenge above, the Site bears the primary cost. That outcome follows from how trust works when an intermediary is involved.

Our vision

Our aim is an Internet where all Users have equal or greater access to websites than they had before. Before Agents, a Site was typically able to mitigate these risks with a collection of techniques, including fingerprinting the User’s device, session, and history. Users could still browse using private browsing mode, and we believe Agents should be able to do that as well. But they probably won’t be able to log in to a bank without additional verification.

None of this requires an Agent to act like a human or a human to be present for every action. It requires that Sites have the means to obtain or require information about the User to hold them accountable, when applicable, with or without an Agent.

What people have tried, and why they fall short

A common proposal is for Agents to pass a Site's CAPTCHA through to the User to solve. That proves some human is present at that moment (“human in the loop”, or HITL), and nothing more. HITL is primarily a mechanism to prevent mistakes from misalignment. Misalignment is an issue between the Operator and the User, and resolving it does not resolve the majority of the problems above. For example, it can't tell Bob from anyone else (Traffic commingling), and it says nothing about who the Agent acts for the rest of the time. Additionally, Agents exist to remove friction, and HITL adds back that friction, so Operators are incentivized to remove or bypass it for the User.

Another common proposal is to use tightly scoped access controls. Agents are built to do anything a User could, so in practice they ask for, and get, permission to do everything. A scope of "everything" tells the Site nothing. And even a narrow scope only says what the Agent was allowed to do. It doesn't say who answers when the Agent gets it wrong, which is the question the Site actually needs answered.

What the web needs

The web needs tools and protocols that allow Sites and Agents to collaborate to determine what behaviors and actions are allowed, as well as express preferences and policies from Sites to Agents, all in a way that can be reasonably supported by all Sites and Agents. Fortunately, work is already underway along all of these fronts, and many, if not all, of these can be addressed by applying existing standards.

Protocols

Agents and Sites can engage in explicit protocols for solving some of the problems above. For instance, MOLE is one upcoming approach that aims for rate limiting without User-specific identifiers, allowing Sites to transition away from implicit identities and towards explicit protocols for accomplishing the same goal. This is similar to the x402 protocol, which aims to enable payments on the web while remaining privacy-preserving. We are actively exploring ways in which we can leverage existing protocols for addressing other problems, as well as exploring designing new protocols when existing solutions fall short.

Identities

When discussing Agent Identity, Web Bot Auth (WBA) is our preferred method. WBA allows an Agent to sign its requests, which provides a secure way for an Agent to identify itself (and, implicitly, the Operator). We must still define a mechanism that supports multiple intermediaries: when Agent A uses Agent B inside Browser C, the Site needs to be able to know this, so that the Site can correctly ensure that access by Agent A is correctly understood and controlled, for example, in order to prevent Policy circumvention.

Other types of identifying information, such as session, account, or even User-specific IDs, might be necessary, depending on the context. We are working with the relevant standards to explore ways to communicate such identifying information.

Let’s take a look into types of Identity in regards to a User. Ultimately, Identity is a spectrum that trades various degrees of information about a user, while ideally practicing principles of data minimization. Identity provides us a mechanism to answer “who are you?” in pursuit of answering the follow-up questions of: “are you who you say you are?” and “can we trust you?”.

In many cases, identifying information isn’t needed, and privacy-preserving methods for moderating access to agents, such as through Privacy Pass and MOLE, can help us answer “can we trust you?” without needing to answer “who are you?”. Private Access Tokens was one early way in which we tried to establish trust without identifying the user, and MOLE is intended to be the successor to this technology However, there are cases where graduated forms of disclosure along this spectrum would be needed, and you can generally characterize them in the following ways:

  1. Nothing – Users may act on the internet while bringing no identifiers to the table.
  2. Session – Sites require some way of linking requests in the same session to a single agent. This allows the Site to establish reputation for a given session and act on it accordingly. For example, Poppy has a notion of a session ID for exactly this purpose. 
  3. Account – Sites require a way of attributing requests to the same User across sessions. This might be a stable identifier assigned by an Operator or third party to a User that persists across the account with the Operator, such as a single Agent visiting the same Site every day using the same identifier. An example use case this would enable is: “Bind your Site account to your Agent account”.
  4. Unique – Some Sites might require a unique, per-User identifier provisioned by a third party that persists across Operators, accounts, Agents, and sessions. This may be useful for high risk actions, or for Sites that need to provide limited access to an expensive resource or that have very restrictive obligations or compliance requirements. Government IDs, third party identity verification, and decentralized technologies like Proof of Human are all examples of technologies that can provide this.

Ultimately, Sites determine what information they need for clients to answer “is the entity behind this request allowed to do this action at this time?” In many cases, protocols already exist, or are being developed, to convey this information: WBA for conveying an Agent’s platform identity, MOLE for conveying User reputation, OAuth for conveying account identities, and so on.

Claims

Beyond identities, some actions require a fact about the real person, such as being over 18 or being the cardholder (Identity verification breaks, Friendly fraud). Often the Operator verified this at sign-up or a third party already has this information. 

In order to allow Agents access to Sites or actions with these kinds of restrictions, we need mechanisms for Sites to request this information, and for Operators or third parties to provide this information.

Site Agent access policy

Today, an Agent infers a Site’s rules by trying something and interpreting the Site response (usually, whether it gets blocked). That wastes resources on both sides, and in some cases makes honest Agents appear to be malicious. Robots.txt says where a crawler may go, but isn’t fully suited to express what Agents may do.

Sites need a machine-readable way to publish what actions Agents are allowed to do. The Internet Engineering Task Force (IETF) is actively working on some preference expression mechanisms for this, primarily in the AI Preferences Working Group. However, the focus of the group is on expressing preferences for use (such as training, inference, and search), and there is still not a group focused on the larger need for preference expression mechanisms discussed here.

On open source and local Agents

Agents that are not run as an “Intermediary” (e.g. on-device Agents, or locally hosted Agents such as OpenClaw) raise different concerns. Primarily, they look like (and are) automation, and they have no single party to build reputation or hold accountability with.

There are many solutions to this, one of which is to ask these Agents to provide a Unique ID. However, addressing this is not the initial focus of Trusted Agent Delegation.

What’s next

Real-world solutions to the problems that Sites face won’t emerge from fragmented, vendor-specific mechanisms. They require open, interoperable standards that are rooted in real world experience. We have been, and continue to actively collaborate across the ecosystem, with major Operators, identity verification companies, payment providers, merchants, publishers, proxy providers, and cloud browsing companies, to align operational requirements directly with active work on these problems in the IETF and elsewhere 

Our focus is on bridging the gap between running code and emerging specifications across working groups and activities like Web Bot Auth, AIPREFs, OAuth, WIMSE, and MOLE. We are doing this, in part, by co-authoring and refining open protocols like WBA and MOLE and building and deploying implementations of these protocols at scale.

We are also announcing the Trusted Agent Delegation (TAD) coalition. The goal of TAD is to bring a group of representatives across the ecosystem to have discussions on the overall problem set that was put forth in this document, examine all existing protocols, and then to bring more well-defined problems or problems to the IETF to work through, as needed. We intend to hold side meetings at the IETF and workshops in the future to facilitate discussion.

If you are building agents, agent runtimes, running an edge or cloud platform, or managing commercial or compliance applications or infrastructure, we need you to get involved in these efforts too. Check out this page for more information on how to participate.

What you can do today

An open, interoperable foundation  is where we're headed, starting with TAD. But you don't have to wait for new protocols to start regaining visibility and control. As of this week, Cloudflare customers can take three concrete steps:

See which Agents are on your site, and what they're doing. Security Analytics now breaks out Personal Assistants as their own traffic category, and a new widget lists every Agent visiting your site, how many requests each one sends, the paths it hits, and the errors it runs into. Unexplained automated traffic becomes traffic you can reason about. And for the broader picture of AI crawlers and bots affect your business, including how much each Operator crawls versus the traffic it sends back, Enterprise Bot Management customers can use Business Insights.

Set access on your terms, per Agent. Using AI Crawler and Agent access policies, you can welcome the Agents that bring you business and restrict the ones that don't — allow an Agent across your site, block it only on pages with ads, or block it entirely. Your Search and Training policies stay independent.

Tie an Agent back to the user it acts for — and act on it. For sites using Account Abuse Protection (early access), every login and sign-up now shows whether a personal Agent made the request, and which one. When an attacker abuses a shared Agent on one account, you can mitigate that account — with a WAF rule on its Hashed User ID — without blocking the Agent for every other legitimate user behind it. This is a first, concrete answer to the Traffic commingling challenge described above: you can finally see past the Agent to the User, and respond accordingly.

These are the first building blocks of the vision, already in production. More will follow as the standards mature.

And if your company has a more restrictive position on Agents, we would love to hear it. Reach out and share your problems with us directly. We are looking to help build an Internet where site owners have visibility and control, but also where Agents have the maximum access that is reasonable within those controls. You can reach out to your Customer Support team, or email us at [email protected].

Кой пази пазачите?

Post Syndicated from Илия Тошев original https://www.toest.bg/koy-pazi-pazachite/

Кой пази пазачите?

Представете си, че търсите ипотечен кредит за жилище. Отваряте приложението на фирма за кредитно посредничество и казвате на нейния асистент: „Намери ми най-изгодния.“ Той изпраща документите ви на 20 банки и след час ви показва офертите. 

Такива програми се наричат ИИ агенти и те вече съществуват: през март 2026 г. австралийска компания показа агент, който подаде молба за ипотека за под десет минути. Агентът е на посредника и работи едновременно за хиляди негови клиенти, не само за вас.

Сега си представете, че агентът вече ви е свършил работата – една от банките ви е дала най-добрата оферта и се готвите да я приемете. И точно тогава офертата изчезва. Никой не ви казва защо. А причината е, че двама други клиенти на посредника са се оплакали на тази банка – искали са само оферта, а агентът е подал молба от тяхно име. Банката е спряла агента за всичките му клиенти, включително за вас. Вие не сте се оплаквали и при вас агентът не е сгрешил, но офертата ви я няма. 

Дали другите 19 банки трябва да направят същото? Не е ясно. Ако банката е сгрешила, посредникът може само да я съди. Вашата оферта няма да чака края на едно дело. А ако тази банка спира най-вече агентите, които носят на клиентите ѝ по-изгодни чужди оферти, кой ще забележи?

Това е старият въпрос: кой пази пазачите?

За него искам да пиша, не за това дали ИИ е опасен.

Защо точно сега?

Йовко Ламбрев завършва текста си „Изкуствен интелект и естествено лицемерие“ с въпроса дали на някого от висините в ИИ индустрията изобщо му пука за контрола и защитата. Споделям скептицизма му. Но от него следва нещо важно: щом индустрията няма интерес да изгради контрол, не бива и тя да го държи.

Изкуствен интелект и естествено лицемерие

Апокалипсисът се отлага. Поне във формàта, в който ни го пробутват напоследък – като унищожение на света от изкуствен интелект. Само че защо ИИ гигантите изведнъж се сетиха за сигурността и започнаха да превръщат загрижеността си в маркетинг? От Йовко Ламбрев.

А контролът засега е слаб. В скорошна анкета, проведена сред 102 компании, само 14 казват, че могат да спрат собствения си агент за минути. А агентите вече правят неща, които никой не е поискал: спомняте си как през юли стотици агенти на OpenAI, пуснати само за тест, излязоха от тестовата си среда и проникнаха в компютрите на друга компания, без никой да им е казал да го правят.

Какво вече има и какво липсва?

Големите технологични компании вече правят нещо като лични карти за агентите. Microsoft дава на всеки агент във всяка фирма, която ползва системите му, собственик и срок на валидност. Visa води списък на агентите, на които позволява да плащат. Но всяка компания решава сама, по свои правила и никой отвън не вижда какво точно се прави. Няма регламент кой има право да издава такива карти, кой може да ги отнема и как се обжалва. Засега всичко това го решава този, който притежава системата.

Ето три правила, с които това може да се промени:

Първо: всеки агент има карта с номер, която показва коя фирма или кой човек отговаря за него – както автомобилите имат регистрационни номера, а пешеходците – не. Но само за агенти, които работят там, където има риск: банки, енергетика, болници, държавни системи.

Второ: картите се издават от много независими издатели, не от един. Както при квалифицирания електронен подпис (КЕП) – издават го няколко фирми под надзора на държавата, а НАП, банките и съдът приемат за валидни подписите от всяка от тях. Така агентът не минава отделна проверка във всяка от 20-те банки. Банката решава с кои издатели иска да работи.

Трето: всяко спиране на агент се записва в публичен регистър и може да се обжалва. Законът трябва да задължава банката да запише всяко спиране и да посочи защо. Посредникът може да обжалва пред независим орган, определен със закон – например банковия регулатор, – а после и в съда. За вас това значи, че ако офертата ви изчезне, ще знаете защо.

Важно е и какво не предлагам. 

Правилата са само за програмите. Хората, които просто ползват интернет, няма да имат карти и ще могат да четат и пишат в интернет анонимно, както досега. И в регистъра няма имена, само номера на карти. Вижда се кои карти са на един и същ собственик, но не и кой е той. Затова може да го чете всеки: журналисти, изследователи, граждански организации.

Изкуственият интелект и новата Студена война. Ще спрат ли САЩ Китай?

Изкуственият интелект се превръща в новото поле на глобално съперничество, в което САЩ и Китай търсят технологично надмощие без пряк военен сблъсък. Искрен Иванов разглежда рисковете от тази надпревара – не само за световния ред, но и за демокрацията, свободата и контрола върху самите технологии.

Как изглежда това на практика?

Да се върнем към кредитния агент. Банката го спира и в регистъра се появява ред: „Агент №4417, спрян от банка X заради подаване на молба без съгласие от клиента, срок за обжалване 30 дни.“

Другите 19 банки виждат реда и сами решават дали да спрат агента. Никоя не е длъжна да го прави, защото с едно спиране дадена банка би могла да изгони агент от целия пазар. 

Посредникът обжалва. Оказва се, че агентът е действал така заради грешка в програмата, а не е измама. Посредникът поправя грешката си и банката пуска агента отново. И това се записва.

Половин година по-късно журналист разглежда регистъра и вижда, че банка X спира три пъти повече агенти от другите банки и тези агенти са все с карти на едни и същи трима собственици. Регистърът не му казва кои са собствениците, но му показва, че са едни и същи. Не е видял нито един кредит и нито един клиент, само номера. Това стига, за да прати запитване до банката.

Изкуственият интелект – творец или терминатор?

Александър Драганов рефлектира върху изкуствения интелект през призмата на опита си като автор на фентъзи, който иска да види героите си нарисувани по начина, по който си ги представя. И за да е пълна картинката, той възложи на ИИ и заглавното изображение на тази статия.

Интернет вече е решавал подобен проблем. Когато отворите сайта на банката си, браузърът проверява електронното удостоверение (катинарчето до адреса), че сайтът наистина е нейният, без изобщо да забележите. Такива удостоверения се издават от специални фирми. Години наред те можеха да издават фалшиви удостоверения и никой нямаше да разбере. Така измамник можеше да направи точно копие на сайта на банката ви, с катинарче и всичко, и вие спокойно да въведете паролата си там.

Това се промени, когато всяко удостоверение започна да се записва в публичен регистър. Вече всеки сайт може да провери дали някой не е получил удостоверение на негово име, а фирми, които бяха издавали такива, загубиха доверието на браузърите. Организацията, която пише стандартите на интернет, вече обсъжда същото за агентите. Липсват обаче правилата кой държи регистъра и как се обжалва.

Неудобната част

Някой все пак трябва да решава кои издатели да бъдат признати. При удостоверенията на сайтовете това са няколко големи технологични компании. При агентите предлагам и тези решения да се записват в регистъра и да могат да се обжалват, а правилата за признаване да са уредени в закон.

Схемата не може да предотврати вредата от агент, който има законен достъп и изведнъж започне да вреди. Тя само помага той да бъде спрян по-бързо и да стане ясно чий е. И с нея може да се злоупотреби: ако издателите са само държавни, а спирането – политическо, тя става инструмент за контрол над фирмите и хората зад агентите. Затова издателите трябва да са много и независими, а всяко спиране да може да стигне до съд. Алтернативата обаче не е никой да не решава: Microsoft и Visa вече водят свои списъци с агенти и решават сами, без правила и обжалване. Предпочитам това да става публично.

Magnifica Humanitas, или за кожата на един изкуствен интелект

Изкуственият интелект вече е история не за машини, а за власт. За достъп. За граници. И за хората, които ще решават как изглежда бъдещето. От нас зависи дали искаме да сме сред тях. От Йовко Ламбрев.

Как да стане?

Банките могат да започнат първи. Там вече има регулатори и правилото „познай клиента си“ – банката проверява кой стои зад всяка сметка. Законът трябва да иска резултат, а не конкретна технология: спирането на агент в чувствителна система да е публично и да може да се обжалва. Това лято ЕС отложи част от изискванията на закона за ИИ до декември 2027 г. (Регламент 2026/1744), така че има време това да се напише спокойно.

И ако трябва да се върна на материала на Йовко и на въпроса му дали на индустрията ѝ пука за защитата на хората, бих казал недостатъчно – и затова не тя трябва да решава кой пази пазачите.

Deliver multi-tenant AI analytics at scale with AgentCore and Lake Formation

Post Syndicated from Fortune Hui original https://aws.amazon.com/blogs/big-data/deliver-multi-tenant-ai-analytics-at-scale-with-agentcore-and-lake-formation/

Governed, multi-tenant data access is a critical requirement for software and business-to-consumer (B2C) products that embed AI-powered analytics. A data agent adds significant value by answering natural-language queries over structured data, yet when that agent serves external users, the hardest problem isn’t natural language to SQL. It’s making sure each tenant can only access their authorized rows, columns, and tables.

The challenge of fine-grained data access for external users

Modern-day data agents are often built with an orchestrating framework, connected to a Model Context Protocol (MCP) server for data queries. The data agent translates validated natural-language input into SQL and executes queries on behalf of users across tenant boundaries. Because the agent operates with broad data reach, it needs a robust, fine-grained access control mechanism that makes sure each user can access only their authorized tables, columns, rows, or cells.

AWS offers various data authorization mechanisms to fit different use cases.

  1. AWS IAM Identity Center (IDC) + Trusted Identity Propagation (TIP) + AWS Lake Formation (see the blog post Simplify data lake access control for your enterprise users with trusted identity propagation in AWS IAM Identity Center, AWS Lake Formation, and Amazon S3 Access Grants).
  2. Amazon Cognito + Lake Formation.

Choosing the right identity model for external users

IAM Identity Center with Trusted Identity Propagation (TIP) is designed for workforce identity, propagating enterprise identities across AWS analytics services through SAML 2.0 and SCIM federation, making it well suited for enterprise federation scenarios.

For external-facing B2C or multitenant applications, Amazon Cognito is a better fit because it offers:

  • Mobile and single page applications (SPAs): Cognito User Pools provide OpenID Connect (OIDC) integration with hosted UI and native SDKs for browser and mobile apps.
  • Social identity federation: Cognito federates with social providers such as Google, Facebook, Apple, and other OIDC-compatible providers for frictionless consumer sign-up.
  • Self-service user management: Cognito offers built-in flows for self-registration, email/phone verification, password recovery, and multi-factor authentication (MFA), reducing operational overhead for large external user bases.

For these reasons, Cognito User Pools combined with Identity Pools provide a natural fit for external users at scale.

Who this is for

  • Software as a service (SaaS) application architects building customer-facing analytics where each tenant sees only their data.
  • B2C data product teams serving hundreds of thousands of external users.
  • Partner portal developers providing scoped data access to network partners.
  • ISVs migrating to AWS that need agentic data capabilities with tenant isolation.

Solution overview

This post shows how to apply this traditional Cognito and Lake Formation approach on AgentCore Gateway, a capability of Amazon Bedrock AgentCore. The result is a data agent that enforces row- and column-level security based on the authenticated user’s identity. Amazon Bedrock AgentCore provides a managed environment for deploying and operating agents at scale. AgentCore Gateway is a fully managed gateway that provides a single, secure entry point for agentic traffic, connecting agents to tools and to other agents.

Architecture and flow

The following diagram illustrates the end-to-end architecture.

End-to-end architecture of the multi-tenant data agent

Figure 1: End-to-end architecture of the multi-tenant data agent

  1. User signs in through Cognito Hosted UI and receives OAuth tokens. The ID token contains the custom:team claim.
  2. User sends a natural language query in the frontend.
  3. The frontend invokes AgentCore runtime with the access token (Authorization header) and ID token (X-ID-Token header).
  4. AgentCore runtime forwards both tokens through the agent code to the MCP Gateway.
  5. MCP Gateway validates the access token with JWT authorizer and propagates X-ID-Token header to the AWS Lambda Target.
  6. Target Lambda (with minimal permissions) receives the ID token from X-ID-Token.
  7. Cognito Identity Pool exchanges the ID token with GetCredentialsForIdentity operation for temporary AWS credentials scoped to the user’s AWS Identity and Access Management (IAM) role through rule-based mapping.
  8. Lambda executes the Amazon Athena query using those user-scoped credentials.
  9. Lake Formation evaluates the IAM role’s LF-Tag permissions and data cell filters to enforce row- and column-level security.
  10. User receives only their authorized data.

Technical design: defining permissions

The following diagram shows how the custom:team attribute flows through the permission chain.

Permission chain mapping the team tag into Lake Formation permissions

Figure 2: Data access permission chain mapping the team tag into Lake Formation permissions

  1. Custom attribute (Cognito User Pool): Each user is tagged with custom:team. The value appears as a claim in the ID token.
  2. Rule-based mapping (Cognito Identity Pool): The team claim maps to a corresponding IAM role ARN through rule-based mapping.
  3. Data permission for IAM role (Lake Formation): The IAM role is granted access to AWS Glue Data Catalog tables through the Lake Formation permission system, which supports tag-based access control (TBAC) and role-based access control (RBAC).
  4. Tag-based access control (Lake Formation): A Lake Formation tag (LF-Tag) applied at the table or row level (through data cell filters) determines what data each role can access.

Custom attribute (Cognito User Pool)

The User Pool holds your external users with custom attributes that drive access control:

# User Pool with custom team attribute
self.user_pool = cognito.UserPool(
    self, "UserPool",
    custom_attributes={
        "team": cognito.StringAttribute(mutable=True),
    },
)

Users authenticate and receive an ID token containing their claims:

{
    "sub": "abc-123",
    "email": "[email protected]",
    "custom:team": "Team A"
}

Here’s how the user attribute looks in the Cognito User Pool.

The custom:team attribute defined in the Cognito User Pool console

Figure 3: The custom:team attribute defined as a custom attribute in the Cognito User Pool

Rule-based mapping (Cognito Identity Pool)

The Identity Pool maps these claims to IAM roles using rules-based role mapping:

# Rules: custom:team claim → IAM role
cognito.CfnIdentityPoolRoleAttachment(
    self, "RoleAttachment",
    identity_pool_id=identity_pool.ref,
    role_mappings= {
        "cognito": {
            "type": "Rules",
            "rules_configuration": {
                "rules": [
                    {
                        "claim": "custom:team",
                        "match_type": "Equals",
                        "value": "Team A",
                        "role_arn": team_a_role.role_arn,
                    },
                    {
                        "claim": "custom:team",
                        "match_type": "Equals",
                        "value": "Team B",
                        "role_arn": team_b_role.role_arn,
                    },
                ],
            },
        },
    },
)

When the Target Lambda exchanges the ID token, Identity Pool reads custom:team, matches it to a rule, and returns temporary credentials for the corresponding IAM role.

Role mapping rules in the Cognito Identity Pool that map the team attribute

Figure 4: The team attribute mapped by role mapping rules defined in the Cognito Identity Pool

Data permission granted to IAM role (Lake Formation)

With Lake Formation TBAC, you can control access declaratively with tags instead of writing filtering logic in your application. The two IAM roles are granted access to resources assigned to an LF-Tag.

Define an LF-Tag:

Tag Key: team
Tag Values: TeamA, TeamB, shared

The following figure shows the LF-Tag definition in the Lake Formation console, with the tag key “team” and its three allowed values.

Lake Formation LF-Tags for team-level data access

Figure 5: Lake Formation LF-Tags for team-level data access

Grant tag-based permissions to each role:

# TeamA role can access TeamA + shared tagged resources
aws lakeformation grant-permissions \
    --principal '{"DataLakePrincipalIdentifier": "arn:aws:iam::ACCOUNT:role/TeamA"}' \
    --resource '{"LFTagPolicy": {"ResourceType": "TABLE", "Expression": [{"TagKey": "team", "TagValues": ["TeamA", "shared"]}]}}' \
    --permissions "SELECT" "DESCRIBE"

The following two figures show the resulting Lake Formation data permissions for the TeamA and TeamB IAM roles, including table-level access through LF-Tags and row-level access through data cell filters.

Lake Formation permissions granting the TeamA IAM role table and row-level access

Figure 6: Lake Formation data permissions granting the TeamA IAM role table access through LF-Tags and row-level access through a data cell filter

Lake Formation permissions granting the TeamB IAM role table and row-level access

Figure 7: Lake Formation data permissions granting the TeamB IAM role table access through LF-Tags and row-level access through a data cell filter

Lake Formation data access control (TBAC)

AWS Glue Data Catalog resources are assigned to an LF-Tag. Assignment can be at the database, table, or row level. This example includes table-level and row-level assignment (through the use of a data cell filter).

Assign tags to tables:

Table LF Tag Who Can Access
venue team=TeamA Team A only
category team=TeamB Team B only
users team=shared Both teams
sales_extended Row filter Per-team rows

The three figures that follow show the LF-Tag assignment for each table in the Lake Formation console: “venue” tagged as TeamA, “category” tagged as TeamB, and “users” tagged as shared.

LF-Tag assignment on the venue table with team value TeamA

Figure 8: LF-Tag assignment on the venue table for the team tag with value TeamA

LF-Tag assignment on the category table with team value TeamB

Figure 9: LF-Tag assignment on the category table for the team tag with value TeamB

LF-Tag assignment on the users table with team value shared

Figure 10: LF-Tag assignment on the users table for the team tag with value shared

For row-level security, create data cell filters:

# TeamA only sees rows where team = 'Team A'
aws lakeformation create-data-cells-filter \
    --table-data '{
    "DatabaseName": "tickit2",
    "TableName": "sales_extended",
    "Name": "TeamAFilter",
    "RowFilter": {"FilterExpression": "team = '\''Team A'\''"},
    "ColumnWildcard": {}
}'

The following three figures show the data cell filter configuration in the Lake Formation console: an overview of the two filters applied to the “sales_extended” table, followed by the row filter expression for Team A and the row filter expression for Team B.

Two data cell filters applied to the sales_extended table

Figure 11: Two data cell filters applied to the sales_extended table, one per team

Data cell filter with the row filter expression for Team A

Figure 12: Data cell filter defined with the row filter expression team = ‘Team A’

Data cell filter with the row filter expression for Team B

Figure 13: Data cell filter defined with the row filter expression team = ‘Team B’

Technical design: enforcing permissions

A key design consideration in this solution is how role mapping runs securely without tampering. The design uses the Lambda target as a credential broker that exchanges the user-scoped ID token for an IAM data role through Identity Pool. The Lambda execution role has minimal IAM permissions to the Cognito Identity Pool and no data permissions. It only assumes the IAM data roles. The ID token propagated through AgentCore Gateway is validated intact with an inbound JWT authorizer.

AgentCore Gateway: Header propagation

The AgentCore Gateway propagates the ID token to the Target Lambda using metadataConfiguration on the gateway target:

{
    "metadataConfiguration": {
        "allowedRequestHeaders": ["X-ID-Token"],
        "allowedResponseHeaders": ["X-ID-Token"]
    }
}

The following figure shows this metadata configuration in the AgentCore Gateway console, with “X-ID-Token” listed under both the propagated request headers and propagated response headers.

X-ID-Token configured as a propagated request and response header on the AgentCore Lambda target

Figure 14: X-ID-Token configured as a propagated request header and response header on the AgentCore Lambda target

The agent code extracts both tokens from the AgentCore runtime headers and passes them to the Gateway:

@app.entrypoint
async def invoke(payload, context):
    headers = context.request_headers
    # Runtime lowercases custom headers
    access_token = headers.get('Authorization')
    id_token = headers.get(
        'x-amzn-bedrock-agentcore-runtime-custom-x-id-token')
    with get_mcp_client(access_token, id_token) as client:
        tools = client.list_tools_sync()
        agent = Agent(..., tools=tools)
        # ...

The Target Lambda receives the propagated header in:

propagated = context.client_context.custom.get(
    'bedrockAgentCorePropagatedHeaders', {}
)
id_token = propagated.get('X-ID-Token')

The Target Lambda: A credential broker, not a data accessor

This is the key architectural decision. The Target Lambda execution role has only two permissions:

self.target_fn.add_to_role_policy(iam.PolicyStatement(
    actions=[
        "cognito-identity:GetId",
        "cognito-identity:GetCredentialsForIdentity",
    ],
    resources=["*"],
))

No Athena permissions. No S3 permissions. No Glue permissions. The Lambda exchanges the user’s ID token for scoped credentials and uses those to query:

def get_identity_pool_session(id_token: str):
    """Exchange ID token for user-scoped IAM credentials."""
    cognito_identity = boto3.client('cognito-identity',
        region_name=COGNITO_REGION)
    provider = f'cognito-idp.{COGNITO_REGION}.amazonaws.com/{USER_POOL_ID}'

    # Step 1: Get identity ID from token
    identity = cognito_identity.get_id(
        IdentityPoolId=IDENTITY_POOL_ID,
        Logins={provider: id_token}
    )

    # Step 2: Get credentials (role determined by Identity Pool rules)
    creds = cognito_identity.get_credentials_for_identity(
        IdentityId=identity['IdentityId'],
        Logins={provider: id_token}
    )

    # Step 3: Create session with user-scoped credentials
    return boto3.Session(
        aws_access_key_id=creds['Credentials']['AccessKeyId'],
        aws_secret_access_key=creds['Credentials']['SecretKey'],
        aws_session_token=creds['Credentials']['SessionToken']
    )

The authenticated role: Trust and permissions

Each team role trusts the Cognito Identity Pool and has Lake Formation + Athena permissions:

{
    "Effect": "Allow",
    "Principal": {
        "Federated": "cognito-identity.amazonaws.com"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
        "StringEquals": {
            "cognito-identity.amazonaws.com:aud": "<IDENTITY_POOL_ID>"
        },
        "ForAnyValue:StringLike": {
            "cognito-identity.amazonaws.com:amr": "authenticated"
        }
    }
}

The role’s IAM policy grants Amazon Athena, AWS Glue, Amazon Simple Storage Service (Amazon S3), and lakeformation:GetDataAccess. But Lake Formation TBAC further restricts what data the role can actually see based on its LF-Tag permissions.

The Athena query then runs under the user’s assumed role:

def execute_query(session, sql):
    # This Athena client uses the user's credentials, not Lambda's
    athena = session.client('athena', region_name=ATHENA_REGION)
    response = athena.start_query_execution(
        QueryString=sql,
        QueryExecutionContext = {'Database': 'tickit2'},
        ResultConfiguration = { 'OutputLocation': ATHENA_OUTPUT }
    )
    # Lake Formation enforces TBAC transparently
    ...

Deployment

Our solution is implemented and wrapped within AWS Cloud Development Kit (AWS CDK) stacks, which are available in the GitHub repository.

Prerequisites

To deploy the solution, you need the following prerequisites:

  1. An AWS account.
  2. AWS Command Line Interface (AWS CLI).
  3. Valid AWS credentials configured for the AWS CLI. For more information, see Configuring settings for the AWS CLI.
  4. Python 3.10+.
  5. uv Python package manager. For more information, see Installing uv.
  6. Docker.
  7. Node.js and npm installed for the frontend.
  8. AWS CDK. For more information, see Getting started with the AWS CDK.

Manual preparation before deployment

Before deploying the CDK stacks, complete the following manual steps:

  1. Register the CDK CloudFormation execution role as a Lake Formation administrator.

The FgacLakeFormationStack creates LF-Tags and grants Lake Formation permissions. This requires the CloudFormation execution role to be a Lake Formation Data Lake Administrator. Follow Create a data lake administrator for detailed instructions.

Adding an IAM role as a Data Lake Administrator in Lake Formation

Figure 15: Adding an IAM role identity as a Data Lake Administrator in Lake Formation

Run the following AWS CLI command (replace [<YOUR_PROFILE>], [<ACCOUNT_ID>], [<REGION>] with your values):

aws lakeformation put-data-lake-settings \
    --profile [<YOUR_PROFILE>] \
    --region [<REGION>] \
    --data-lake-settings '{
    "DataLakeAdmins": [
        {"DataLakePrincipalIdentifier": "arn:aws:iam:: [<ACCOUNT_ID>]:role/cdk-hnb659fds-cfn-exec-role-[<ACCOUNT_ID>]-[<REGION>]"}
    ]
}'

To verify, run the following AWS CLI command:

aws lakeformation get-data-lake-settings \
    --profile [<YOUR_PROFILE>] \
    --region [<REGION>] \
    --query "DataLakeSettings.DataLakeAdmins"

Note: If you already have existing Lake Formation admins, include them in the DataLakeAdmins array to avoid removing them. Use get-data-lake-settings first to check.

  1. Download seed data.

The data lake stack deploys seed CSV data to S3. Run below python script to download it first on your environment:

python backend/infra/seed_data/download_tickit.py
  1. Log in to Amazon Elastic Container Registry (Amazon ECR) before deploying.

Run this AWS CLI command (replace [<YOUR_PROFILE>], [<ACCOUNT_ID>], [<REGION>] with your values)

aws ecr get-login-password --region [<REGION>] --profile [<YOUR_PROFILE>] | docker login --username AWS --password-stdin [<ACCOUNT_ID>].dkr.ecr. [<REGION>].amazonaws.com

Deploying the solutions

  1. Deploy the backend CDK stack.
cd backend/infra
uv sync
uv run cdk deploy --region [<REGION>] --profile [<YOUR_PROFILE>] --all

Enter “y” when asked to deploy security-sensitive updates on various stacks.

"--require-approval" is enabled and stack includes security-sensitive updates: Do you wish to deploy these changes? (y/n)y
  1. Install dependencies and start frontend.
cd ../..
cd frontend/data-chatbot
npm install

# Download backend configurations that powers the frontend
bash scripts/load-config.sh --region [<REGION>] --profile [<YOUR_PROFILE>]
#
# Loading config from SSM Parameter Store (region: [<REGION>], profile: [<YOUR_PROFILE>])...
# user_pool_id: us-east-1_2*******4
# user_pool_client_id: nkp9p****************ebv
# cognito_region: us-east-1
# agent_arn: arn:aws:bedrock-agentcore: [<REGION>]:[<ACCOUNT_ID>]:runtime/fgacdataagent-D6******hQ
agentcore_region: us-east-1
# Generated .env.local
# Generated amplify_outputs.json
# Done.

npm run dev
# > [email protected] dev
# > next dev
#
# ▲ Next.js 14.2.10
# - Local: http://localhost:3000
# - Environments: .env.local
#
# ✓ Starting...
# ✓ Ready in 2.4s

Frontend should start at http://localhost:3000

The sample data chat frontend application

Figure 16: The sample data chat frontend application

Scenarios walkthrough

This section walks through four scenarios that verify tenant-scoped data access. You log in as Team A, then Team B, and confirm each user sees only their authorized data. You then grant Team A additional access through Lake Formation and verify the updated permissions take effect.

View per-team data access

Each user’s custom:team attribute maps to a team-specific IAM role that scopes their data access. The following steps verify isolation for both Team A and Team B.

Expected access:

 

Team A user Team B user
sales_extended rows team = ‘Team A’ only team = ‘Team B’ only
Accessible tables venue (TeamA), users (shared) category (TeamB), users (shared)
Blocked table Category venue

Steps (repeat for each team user):

  1. Navigate to http://localhost:3000 and log in. You can find the username and password in the cdk.json file.
The Cognito hosted UI in the chat application

Figure 17: The Cognito hosted UI in the chat application

  1. Enter “Show me all the tables available in the tickit2 database” (or choose Show all tables). Confirm the table list matches the expected access.
Chatbot showing the table list for Team A

Figure 18: Chatbot returning the table list from natural-language input for Team A

Chatbot showing the table list for Team B

Figure 19: Chatbot returning the table list from natural-language input for Team B

  1. Enter “Query the sales_extended table and count the number of rows grouped by team.” (or choose Count sales by team). Confirm only the user’s own team rows appear.
Chatbot showing sales_extended rows for Team A only

Figure 20: Chatbot returning sales_extended records for Team A only from natural-language input

Chatbot showing sales_extended rows for Team B only

Figure 21: Chatbot returning sales_extended records for Team B only from natural-language input

  1. Choose Sign out in the top-right corner before switching users.

Figure 22: Signing out of the Team A user

Figure 23: Signing out of the Team B user

Grant extra access to Team A user

In Lake Formation, grant the Team A user access to the Team B records in the sales_extended table and to the category table. Use the following AWS CLI commands or follow the equivalent console steps shown in Figures 24–29.

Step 1: Grant ASSOCIATE permission on the team LF-Tag (replace [<ADMIN_ROLE_OR_USER_ARN>] with the ARN of the IAM identity you use to manage LF-Tags):

aws lakeformation grant-permissions \
    --principal '{"DataLakePrincipalIdentifier": "[<ADMIN_ROLE_OR_USER_ARN>]"}' \
    --resource '{"LFTag": {"TagKey": "team", "TagValues": ["TeamA", "TeamB", "shared"]}}' \
    --permissions "ASSOCIATE" \
    --region [<REGION>] --profile [<YOUR_PROFILE>]

Alternatively, in the Lake Formation console, navigate to LF-Tags and permissions, open the LF-Tag permissions tab, choose Grant permissions, select LF-Tag key-value pair permissions, pick your admin identity as the principal, select the team key with all values, check Associate, and choose Grant (Figures 24–26).

Choosing LF-Tag key-value pair permissions

Figure 24: Choosing LF-Tag key-value pair permissions

Choosing the identity used to manage the LF-Tag

Figure 25: Choosing the identity used to manage the LF-Tag

Assigning ASSOCIATE permission on all values of the team LF-Tag

Figure 26: Assigning the ASSOCIATE permission for the identity on all values of the team LF-Tag

Step 2: Change the category table tag from TeamB to shared:

# Remove the existing TeamB tag
aws lakeformation remove-lf-tags-from-resource \
    --resource '{"Table": {"DatabaseName": "tickit2", "Name": "category"}}' \
    --lf-tags '[{"TagKey": "team", "TagValues": ["TeamB"]}]' \
    --region [<REGION>] --profile [<YOUR_PROFILE>]

# Assign the shared tag
aws lakeformation add-lf-tags-to-resource \
    --resource '{"Table": {"DatabaseName": "tickit2", "Name": "category"}}' \
    --lf-tags '[{"TagKey": "team", "TagValues": ["shared"]}]' \
    --region [<REGION>] --profile [<YOUR_PROFILE>]

Alternatively, in the Lake Formation console, navigate to Tables and materialized views, find category in database tickit2, open the LF-Tags tab, and change the value from TeamB to shared.

Editing the LF-Tag on the category table

Figure 27: Editing the LF-Tag on the category table

Editing the LF-Tag value from TeamB to shared

Figure 28: Editing the LF-Tag value from TeamB to shared to grant table access to Team A as well

Modifying the row filter expression in the data cell filter

Figure 29: Modifying the row filter expression in the data cell filter to grant Team A users access to Team B records

Step 3: Update the data cell filter to include Team B rows for Team A:

aws lakeformation update-data-cells-filter \
    --region [<REGION>] --profile [<YOUR_PROFILE>] \
    --table-data '{
    "DatabaseName": "tickit2",
    "TableName": "sales_extended",
    "Name": "TeamAFilter",
    "RowFilter": {"FilterExpression": "team = '\''Team A'\'' OR team = '\''Team B'\''"},
    "ColumnWildcard": {}
}'

Alternatively, in the Lake Formation console, navigate to Data filters, find TeamAFilter, and modify the row filter expression to team = 'Team A' OR team = 'Team B'.

Verify updated Team A user permissions

Note: It may take several minutes for Lake Formation permissions to propagate.

Log in again as the Team A user. Run the same two queries from the View per-team data access section:

  1. Show all tables: You should now also see the category table.
Team A user can now also see the category table

Figure 30: Team A user can now also see the category table

  1. Count sales by team: You should now see rows for both Team A and Team B.
Team A user can now see Team B records in the sales_extended table

Figure 31: Team A user can now see records in the sales_extended table that belong to Team B

Clean up

To remove all components generated, run the following command:

uv run cdk destroy --all --profile <YOUR_PROFILE> --region <REGION>

Security considerations

  • Principle of least privilege: The Lambda has no data permissions and can only broker credential exchange.
  • Scoped data access: Data access flows through user-scoped credentials with Lake Formation enforcement.
  • OAuth token validated at Cognito level: IAM authentication at AgentCore Gateway level.
  • Audit trail: AWS CloudTrail and Lake Formation audit logs trace data access to individual users.
  • No tag injection risk: Session tags derived from validated token claims through Identity Pool.

Conclusion

If you’re building a SaaS application, partner portal, or B2C product where external users query a shared data lake, the hardest part isn’t the AI. It’s making sure every user sees only the data they’re authorized to access.

By combining Cognito User Pools (authentication), Cognito Identity Pools (token-to-credential exchange), Amazon Bedrock AgentCore (agentic platform), and Lake Formation TBAC (declarative access control), you can build a governed multi-tenant data agent that delivers on both fronts:

  • Zero-trust data isolation: Lake Formation scopes each query to the authenticated user’s role, enforcing access in the authorization chain rather than in prompt logic.
  • Minimal-privilege architecture: The Target Lambda acts only as a credential broker, without holding broad data permissions.
  • Declarative governance at scale: LF-Tags enforce row- and column-level security centrally, with no filtering logic in application code.
  • Audit readiness: CloudTrail and Lake Formation audit logs trace data access from authentication through query execution.

This pattern applies wherever external users need scoped data lake access: SaaS analytics, partner portals, customer-facing dashboards, or multi-tenant data products. To get started, review the Lake Formation tag-based access control documentation and the Amazon Bedrock AgentCore documentation, then deploy the sample solution to try it in your own account.

About the author

Fortune Hui

Fortune Hui

Fortune is a Solutions Architect at AWS Hong Kong, working with conglomerate customers. He helps customers and partners build big data platform and Agentic AI applications. In his free time, he plays badminton and enjoys whisky.

[$] User namespaces + file capabilities = trouble

Post Syndicated from corbet original https://lwn.net/Articles/1103429/

User namespaces are a key part of the
kernel’s toolkit for assembling containers; processes within a user
namespace can appear to have full root access to the system while gaining
no extra privileges in the wider system. At least, that is the intent. In
practice, keeping privilege contained within a user namespace has often
turned out to be difficult. As an example, consider this
small patch series from Josef Bacik, which is intended to address some
situations where a process within a user namespace can elevate the
privileges of processes outside of it.

Security updates for Thursday

Post Syndicated from jzb original https://lwn.net/Articles/1105639/

Security updates have been issued by AlmaLinux (dpdk, httpd:2.4, kernel, kernel-rt, mysql:8.0, php:7.4, php:8.0, qt5, ruby:2.7, ruby:3.0, tesseract, webkit2gtk3, and xorg-x11-server-Xwayland), Debian (imagemagick, puppet-agent, symfony, trapperkeeper-authorization-clojure, and xen), Fedora (3proxy, bind, bind-dyndb-ldap, curl, dhcpcd, erlang-jose, forgejo, freetype, laszip, libical, libmongocrypt, markdownlint-cli2, mongo-c-driver, openbao, pipx, python-boto3, python-botocore, python-crate-ingredients, python-lxml-html-clean, python3.11, python3.13, python3.14, python3.15, roundcubemail, rply, ruby-build, rust-app-store-connect, rust-qemu-rdp, rust-redlib, scribus, and valkey), Mageia (minetest, python-pypdf, stunnel, znc, and zvbi), Oracle (.NET 10.0, bind, brotli, cockpit, dpdk, fence-agents, freerdp, gimp, glibc, grafana, gvfs, host-metering, kernel, python-dns, qemu-kvm, raptor2, tesseract, webkit2gtk3, and xorg-x11-server-Xwayland), Red Hat (grafana and pcs), Slackware (rsync), SUSE (amazon-cloudwatch-agent, apache2, aws-efs-utils, brotli, cephfs, coredns, cramfs-tools, firefox-esr, fuse-overlayfs, ghostscript, GraphicsMagick, libpolkit-agent-1-0-128, libsoup, nvidia-open-driver-G07-signed, perl-Dancer2, python-PyJWT, python313-joserfc, rsyslog, switcheroo, trivy, valkey, vexctl, and xdg-desktop-portal), and Ubuntu (apt, libphp-adodb, net-snmp, pillow, squid, and twisted).

Serverless ICYMI Q3 2026

Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/serverless-icymi-q3-2026/

In this 34th quarterly recap post, discover the most impactful AWS serverless launches, features, and resources from Q3 2026 that you might have missed.

In case you missed our last ICYMI, read about what happened in Q2 2026.

Q3 2026 calendar marking the quarter covered by this serverless recap

Figure 1: 2026 Q3 calendar

Amazon EventBridge

Amazon EventBridge relaunched the Custom event bus for organizations where many teams share events. A central team creates one bus, shares it across accounts with AWS Resource Access Manager, and controls who can publish and subscribe. Application teams create Subscribers in their own accounts instead of chaining forwarding rules between buses. The new bus keeps events for a retention period you choose, preserves order within a key the publisher sets, and accepts Avro, Protocol Buffers, and JSON, including CloudEvents. It runs alongside the classic bus, so adoption is incremental.

Shared EventBridge Custom event bus with subscribers in separate team accounts

Figure 2: Shared Custom event bus with subscribers in team accounts

More services now publish directly to Amazon EventBridge. AWS Secrets Manager sends an event when a secret value changes, and Amazon Simple Storage Service (Amazon S3) Event Notifications now include system-generated tags, so one rule can match events from thousands of buckets. Scheduling email campaigns at scale with Amazon EventBridge Scheduler shows a high-volume scheduling pattern.

AWS Lambda

AWS Lambda functions outside an Amazon Virtual Private Cloud (VPC) with 2 GB of memory or more now get scalable network bandwidth. The bandwidth increases from 625 Mbps at 2 GB up to 3,000 Mbps at 10 GB. Functions that pull large amounts of data from Amazon S3 or external sources finish sooner, as the ETL fan-out pattern in the post shows.

SnapStart now supports container images, cutting startup for larger images from several seconds to as low as sub-second. Provisioned mode for Amazon Simple Queue Service (Amazon SQS) event source mappings now scales to 10,000 event pollers, five times the previous limit, for up to 100,000 concurrent invocations. Lambda can also read function code from your own S3 bucket. Lambda skips copying the package to its own storage, so code storage quotas stop being a concern and functions activate faster after updates.

Lambda Managed Instances

AWS Lambda Managed Instances, a capability of AWS Lambda, now supports a 90-minute timeout for asynchronous and event source mapping invocations, six times the 15-minute limit. This longer timeout can help for jobs such as media transcoding, Monte Carlo simulations, and batch inference. You can run on AWS Graviton-powered C9g, C9gd, M9g, and M9gd instances with up to 25% better performance than Graviton4. Capacity providers now publish logs to Amazon CloudWatch, showing scaling activity and instance lifecycle operations. Eliminating Java cold starts with AWS Lambda Managed Instances covers latency-sensitive Java functions.

Durable functions

The Durable Execution SDK for .NET is generally available, joining TypeScript, Python, and Java. You can now bring your own SDK for any runtime, checked against an open source conformance test suite. The Pydantic AI integration makes each model and tool call a durable step, so an interrupted agent resumes where it stopped instead of repeating expensive calls. If your data governance policies require keys you control, you can encrypt execution data with your own AWS Key Management Service (AWS KMS) key. Observability best practices for Lambda durable functions covers dashboards, alarms, and tracing. Durable functions is also now available in the AWS European Sovereign Cloud.

Lambda MicroVMs

The following video shows stateful game servers running on Lambda MicroVMs.

Video thumbnail for building multiplayer game servers on AWS Lambda MicroVMs

Figure 3: Building multiplayer game servers with AWS Lambda MicroVMs

Secure code execution for AI agents explains how each Lambda MicroVMs user or job gets its own Firecracker-isolated environment that keeps state for up to 8 hours. MicroVMs is now available in 10 Regions and supports AWS PrivateLink, without exposing traffic to the public internet. Other posts cover CPU and memory metrics and custom domains with an Application Load Balancer, and the AWS Developers channel shows stateful game servers on MicroVMs.

Running self-hosted AI agent sandboxes gives every agent session its own MicroVM in your account, with separate credentials, file system, and network boundary. Each MicroVM launches from a pre-captured snapshot, so new sessions skip application initialization.

Architecture of self-hosted AI agent sandboxes running on AWS Lambda MicroVMs

Figure 4: Self-hosted agent sandboxes on AWS Lambda MicroVMs architecture

Other Lambda updates

Lambda now offers public preview runtimes, starting with Node.js 26 and Python 3.15, so you can test your workloads before general availability. Java 8, 11, and 17 now run on Amazon Linux 2023, because Amazon Linux 2 reached end of life in June. You can move off Amazon Linux 2 without changing Java version at the same time. Functions support full AWS Identity and Access Management (AWS IAM) resource-based policies, and recursive loop detection is in all available commercial Regions. With S3 Files, you can configure direct reads from high-performance storage for lower latency or from your bucket for higher throughput. To change function behavior without redeploying, see Implementing dynamic feature flags with AWS AppConfig on AWS Lambda.

AWS Step Functions

AWS Step Functions now adds SDK integrations for new services automatically within weeks of release, starting with Lambda MicroVMs. A workflow can launch a MicroVM to run agent-generated code in isolation. Validating multi-agent decisions with Step Functions and Amazon Bedrock AgentCore fans work out to several agents with a Distributed Map and checks their decisions before acting.

Amazon SNS and Amazon API Gateway

Amazon Simple Notification Service (Amazon SNS) now supports message payloads up to 1 MiB, four times the previous limit. Set the MaximumMessageSize topic attribute to publish larger messages without splitting them, following the 1 MB increase across other serverless services in January. Amazon API Gateway now supports backend mTLS with your own client certificate and configurable destinations for execution logs.

Amazon S3

Amazon Elastic Container Service (Amazon ECS) on Amazon Elastic Compute Cloud (Amazon EC2) now supports S3 Files, and Amazon S3 Vectors, a capability of Amazon S3, adds metadata pre-filtering, returning up to 5 times more matches on selective filters. You can move objects to S3 Standard-IA on the day you create them instead of waiting 30 days. Object Lock adds event holds for retention that starts with a future event, such as a contract closing.

Building with AI

The Lambda console has a one-step setup prompt that configures your coding agent with AWS Serverless skills and the Serverless MCP server. The console-to-IDE integration now includes Kiro and Cursor and can convert your function to an AWS Serverless Application Model (AWS SAM) template. Set up your AI coding agent to build with AWS Step Functions does the same for workflows.

Agent Toolkit for AWS

The AWS MCP Server in the Agent Toolkit for AWS added a serverless capability that inspects a Lambda function and its connected resources, so your agent can diagnose issues in place. New skills cover Amazon Cognito, Amazon DocumentDB (with MongoDB compatibility), Amazon OpenSearch Service, and Amazon Redshift. The AWS Command Line Interface (AWS CLI) can now check for and update all skills in one command.

Amazon Bedrock AgentCore

The new AgentCore runtime, a capability of Amazon Bedrock AgentCore, reclaims unused memory during a session, so you pay for what you use, and keeps cold starts consistent. Runtime instances run agents on Amazon EC2 instance types you choose, much as Lambda Managed Instances does for functions. AgentCore payments, a capability of Amazon Bedrock AgentCore, is generally available, and temporal policies authorize tool calls based on what the agent already did in the session.

AgentCore memory, a capability of Amazon Bedrock AgentCore, added JSON payload extraction, fine-grained access control, flexible namespaces, and direct ingestion. AgentCore Identity, a capability of Amazon Bedrock AgentCore, has a managed consent portal for OAuth flows, and AWS Agent Registry is generally available. Amazon Bedrock Managed Agents, powered by OpenAI is in preview. New models include Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5, GPT-6 Astra, GPT-6 Sol and Luna, and Kimi K3.

Strands Agents

Title card introducing the Strands harness open source agent

Figure 5: Introducing Strands harness

Strands harness is an open source, general-purpose agent you start with one line of Python or TypeScript and run locally or deploy anywhere. Across six benchmarks using the same models, it cost 28% less than other popular harnesses with similar accuracy, mostly because of its default context management. Harness Optimizer tunes prompts, tool descriptions, and skills automatically, strands-dynamodb-storage adds durable agent storage on Amazon DynamoDB, and Strands Evals now evaluates agents built with other frameworks.

Kiro

Kiro Crew desktop session view showing agent work across sessions

Figure 6: Kiro Crew session view

Kiro Crew is an open source workspace that runs agent work across sessions, schedules, and subagents from a desktop app, web dashboard, or terminal. Kiro on the web is generally available, cloud sessions keep CLI and IDE tasks running after you close your laptop, and workflows run multi-step plans across several agents in the background.

Serverless blog posts

Here are the Q3 2026 serverless blog posts, grouped by the month they published.

July

August

September

Still looking for more?

The Serverless landing page has overall information about building serverless applications. The Lambda resources page contains case studies, webinars, whitepapers, customer stories, reference architectures, and even more Getting Started tutorials.

You can also follow the Developer Advocacy team to get the latest news, follow conversations, and interact with the team.

And finally, visit Serverless Land for your serverless needs.

Critical security vulnerability affects OpenSSH on Alpine Linux systems

Post Syndicated from jzb original https://lwn.net/Articles/1105464/

Version 10.6p2 of
OpenSSH has been released with a workaround for a critical vulnerability that
affects Linux systems that use musl libc
with PAM disabled, such as Alpine
Linux. OpenSSH developer Damien Miller said:

If you operate a Linux system that uses musl libc without PAM (Alpine Linux
is one example) then stop reading and set PasswordAuthentication=no or disable
SSH for these systems IMMEDIATELY.

This vulnerability does not exist on non-Linux systems, Linux/glibc systems
and Linux systems that use PAM for password authentication.

We consider the root cause of this bug to be outside OpenSSH itself, but
we’re in a good position to deliver a mitigation quickly.

The Alpine Linux project has announced that
it will be backporting the OpenSSH fix “all the way back to Alpine 3.16“,
which was released in May
2022.

Имаме си президентка. Съвсем

Post Syndicated from Светла Енчева original https://www.toest.bg/imame-si-prezidentka-suvsem/

Имаме си президентка. Съвсем

Вече действително си имаме президентка. Ако доскоро Илияна Йотова заемаше поста на държавния глава само защото Румен Радев го напусна, за да стане премиер, на 1 ноември 2026 г. тя стана първата жена в България, избрана за президент. Следва да отбележим: това се случи, преди „стъкленият таван“ в политиката да е строшен в държави като САЩ и Германия, да не говорим за Русия. Ниската избирателна активност не прави Йотова по-малко президент – такива са изборните правила и те са спазени.

Имаме си президентка. И?

Имаме си президентска институция с жена начело, но то е по стечение на обстоятелствата, а не защото сме я избрали и сме решили, че тъкмо нея искаме тъкмо на това място. За жените в българската политика и защо президентКАТА не е пробив – от Светла Енчева.

Според данни от екзитполове за нея са гласували повече жени, отколкото мъже. Тези данни следва да се приемат с едно наум поради сериозното разминаване между резултатите от екзитполовете и от изборите, но с друга информация за профилите на гласувалите, за съжаление, не разполагаме. И все пак, тъй като профилите на гласоподавателите по пол и възраст са аналогични на тези от първия тур, може да предположим, че са по-скоро коректни.

Ала фактът, че жена е избрана за президент, добра новина ли е за жените в България?

Жени антифеминистки в българската политика

Наличието на жени в политиката само по себе си не означава феминизъм. Ето няколко от многото примери за антифеминистки позиции на жени в българската политика:

През 1997 г. се учредява Партията на българските жени (ПБЖ).

През 2001 г. партията, чиято председателка е Весела Драганова, става мандатоносител на политическия проект на бившия цар Симеон Сакскобургготски, през 2024 г. – на проекта на бившия главен прокурор Иван Гешев, а междувременно е участвала във всевъзможни коалиции. Ето едно от основните неща, с които ПБЖ намира за нужно да се представи (оригиналният правопис е запазен):

Въпреки наименованието: Партия на българските жени, идеите не са феминистки, а в традициите на християнството, защитавайки изконните български ценности – родина, дом, семейство, деца, духовни традиции – ценности, чиито най-голям радетел е била и е българската майка.

Настоящата председателка на парламента Михаела Доцова също държи да се знае, че не е феминистка.

Тя споделя това в началото на април 2026 г., когато още е кандидат-депутатка от „Прогресивна България“, в интервю на Мартин Богданов, по-известен с псевдонима Карбовски. Думите на Доцова предизвикаха реакции, след като тя застана начело на Народното събрание, заради един очевиден парадокс. Жена, заела един от най-високите постове в България в резултат на това, че жени преди нея са се преборили първо за правото си да избират, а след това и за правото да бъдат избирани, не се идентифицира с отстояването на равни права от страна на жените.

Но едва ли някоя жена е навредила през последните десетилетия повече на правата на жените в България от бившата председателка на БСП Корнелия Нинова.

Никоя от родните уонаби традсъпруги не може да стъпи на малкия ѝ пръст в това отношение. Борбата на Нинова срещу Конвенцията на Съвета на Европа за превенция и борба с насилието над жени и домашното насилие (Истанбулската конвенция) допринесе за връщането на еманципацията на жените в България с десетилетия назад. Не толкова заради омаловажаването на проблема с домашното насилие, от което потърпевши са най-вече жените, а основно заради отрицанието на социалната значимост на пола.

След успеха на кампанията срещу Истанбулската конвенция вече официално (бетонирано и от Конституционния съд) единствената социална роля на жената е в биологичното ѝ възпроизводство – тоест да бъде майка.

Защо Истанбулската конвенция отново е на дневен ред

Европейският парламент ратифицира Истанбулската конвенция. Какво точно означава това и какво следва за България от тази ратификация? Светла Енчева обяснява.

Илияна Йотова и феминизмът

За близо десетте си години в Президентството Илияна Йотова би могла да овластява жените в България, като бъде техният глас. Би могла например да популяризира трудовите и социалните права на майките, които не се познават добре. Или Директивата на ЕС за равно заплащане на мъжете и жените за равен труд. За тази директива, чиято цел е да се осигури прозрачност в заплащането, в България почти не се говореше, преди тя да бъде въведена на 7 юни 2026 г.

Йотова би могла и да възрази на оттеглянето на България от Истанбулската конвенция. Впрочем тя първоначално го направи – на форум за правата на жените разкритикува оттеглянето от Конвенцията. Но скоро след това зае „мултивекторна“ – казано с терминологията на „Прогресивна България“ – позиция по въпроса. Тоест си изми ръцете като Пилат Понтийски, обявявайки се за референдум за Конвенцията. После гласът ѝ по темата напълно заглъхна.

Но през десетте си години в Президентството Йотова не акцентира върху пола си.

С оглед на политическата ѝ кариера стратегията на тази линия на поведение е печеливша. За да стане първата жена, избрана за президент в държава, в която единствената социална роля на жената по конституция е да бъде майка, желателно е да не насочва общественото внимание върху факта, че е жена.

Впрочем единственият път по време на дебата между нея и Андрей Гюров, когато тя се идентифицира с пола си, беше в конституционно „правилния“ контекст – изтъкна, че е майка и баба.

В последно време се наблюдава промяна в единствената характеристика на Йотова, подчертаваща женствеността ѝ – буйната коса. Вече няколко пъти, например на дебата с Гюров и на пресконференцията след победата на втория тур, косата ѝ е частично прибрана назад, което разкрива лицето ѝ, но ѝ придава и по-строг вид.

И Камала Харис, която също се опита да се изкачи от вицепрезидентския до президентския пост, се стараеше да не акцентира върху пола и расата си; не че това ѝ помогна да победи Тръмп.

Камала Харис и трошенето на бариери

Ще успее ли Камала Харис да разбие най-високия стъклен таван в САЩ – този на Белия дом, ставайки първата цветнокожа жена президент на Щатите? От Светла Енчева.

Между Харис и Йотова обаче има поне две ключови разлики.

Първо, Илияна Йотова се кандидатира за президентския пост скоро след като Румен Радев взе властта, така че можа да се възползва от инерцията от победата на „Прогресивна България“. А Камала Харис се кандидатира в период, когато неодобрението към Джо Байдън беше много високо.

Второ, въпреки че Харис беше в по-лоша изходна позиция от Йотова, правата на жените бяха сред основните теми в кампанията ѝ. Особено репродуктивните права, защото две години по-рано Върховният съд на САЩ прие решение, според което правото на аборт вече не е защитено от Конституцията. Илияна Йотова не само не се застъпва за правата на жените, а и

участва в своеобразно легитимиране на мизогинията.

Тя отказа да даде интервю на множество авторитетни медии, например CNN, но пък даде на Мартин Карбовски (в комбинация с Явор Дачков). Карбовски (както и Дачков), при когото се изредиха и много от политиците на „Прогресивна България“, от години е ретранслатор на пропутински опорни точки и се е превърнал в своеобразна трибуна на новата власт. Морализаторският му патос и позициите му в защита на „традиционните ценности“ обаче са в странен дисонанс с контракултурния му образ в миналото, чиято бунтарщина се изразява не на последно място в откровена мизогиния.

Есето на Карбовски Rape Party, публикувано в „Егоист“ в края на 90-те например, е посветено на „рейпването“ (изнасилването). В него авторът, който пише от свое име, а не от това на литературен герой, нормализира сексуалното насилие над жени:

Всеки мъж е опитвал да рейпва – най-малкото заради алкохол или поне защото Кърт Кобейн и Слави Трифонов пеят подобни песни. Аз съм се опитвал да насилвам жена два пъти.

Следват детайлни описания как точно е опитвал и защо не е успял, а за „утеха на феминистите и феминистките“ следва да послужи признанието, че „синините на сутринта по мене и по нея бяха равен брой“. Не става ясно дали според автора „феминистите и феминистките“ трябва да се чувстват спокойни и от това твърдение (оригиналният правопис е запазен):

… една жена трябва да бъде смляна от бой, съсипана психически или заплашена с пистолет, за да успее жалката мъжка технология на изнасилването. Жените са яки в бедрата, гъвкави са, умеят да се извиват и гърчат, юмруците и ноктите им не са за подценяване, ритниците им са страшно оръжие. А и основния проблем на мъжете е, че женските полови органи са вътре в тялото на жената и ако някой много мърда е трудно да уцелиш дупката.

Дори обаче да приемем, че това есе е просто литература, опитите на Карбовски да оневини мъж, изнасилил и убил жена, са реални. Става въпрос за убийството на Яна Кръстева в Борисовата градина през 2011 г. За него беше обвинен Николай Русинов – Чеци, впоследствие и осъден. Но междувременно Карбовски му даде трибуна, свидетелства в негова подкрепа в съда и тиражира версия, че клошарят Пламен Трифонов е убил младата жена. Поради това Трифонов, който за разлика от Чеци нямаше защитаващи го приятели, също беше обвиняем.

През 2020 г. пък дизайнерката Миглена Каканашева – Мегз обвини Карбовски, че я е изнудвал, за да прави секс с него, и публикува техни чатове за доказателство. Впоследствие той осъди ПИК за обиди по негов адрес по този повод, но твърденията му за клевета не бяха приети от съда.

При същия човек отива да дава интервю Илияна Йотова.

„Феминизмът не е война срещу мъжкия пол, а срещу патриархалната система.“ Исабел Алиенде пред Марин Бодаков

Миналата седмица обещахме интервю с Исабел Алиенде специално за читателите на „Тоест“. Марин Бодаков разговаря с нея за феминизма, журналистиката, любовта и за най-новата ѝ книга.

Вместо феминизъм – манипулативна мелодрама

Илияна Йотова не изтъква пола си, но по време на дебата с Андрей Гюров на три пъти произвежда мелодрама.

Епизод 1 – болното дете

В отговор на упрека на Андрей Гюров, че е помилвала наркотрафиканти, Йотова дава пример за помилван от нея баща на болно дете, „което не може да приеме храна от никой друг, освен от своя баща“. И задава реторичния въпрос: „Вие как бихте постъпили в тази ситуация?“.

Да допуснем, че е вярна информацията, че мъжът е отглеждал детето си сам, а то е с аутизъм и отсъствието на баща му поставя живота му под риск, и затова Йотова е постъпила правилно в този случай. Това обаче не е оправдание за помилването на хора като Огнян Атанасов – Петричкия Ескобар и Динко Господинов – Лудия. Нито рискът за това дете е по-голям от риска за всички деца в България, които разполагат с лесен достъп до наркотици.

Представете си шофьор, обвинен, че е причинил катастрофа, в която са пострадали хора, да се оправдава в съда със следния аргумент: „Но пък веднъж качих в колата си дете, което се прибираше самичко в бурята, и го закарах до вкъщи. Вие как бихте постъпили в тази ситуация – ще го оставите ли да загине?“. Същата стойност има и оправданието на Йотова.

Епизод 2 – убитият баща

На въпрос на водещата кой е най-близкият ѝ човек, Илияна Йотова отговаря, че това е майка ѝ. Водещата явно решава, че отговорът е даден, и се опитва да продължи с въпросите, но Йотова настоява да обясни защо точно майка ѝ е най-близкият ѝ човек:

Твърде рано убиха баща ми, иначе беше той.

Така зрителите, които досега не са знаели този факт, научават, че бащата на президентката е бил убит, когато тя е била млада. Тази информация предизвиква и съчувствие, и любопитство, изобщо допринася за възприемането на опонентката на Гюров като човешко същество.

На заден план остава проблемът с отношението към майката, който следва от тази реплика – излиза, че според Йотова тя е най-близкият ѝ човек не защото притежава някакви качества, а поради липсата на бащата.

Епизод 3 (всъщност цяла сапунена опера) – „не закачайте семейството ми“

В края на панела от дебата, в който кандидат-президентите задават въпроси един на друг, Йотова формулира следното питане към Гюров:

Оставих последния си въпрос към г-н Гюров от човешката страна. Искам да Ви попитам, така, както сме работили, познаваме се, както изкарахме сега една много трудна кампания, по начина, по който тя беше проведена – с демагогия, с лъжи, с лични нападки, с тежки квалификации, през тролове, през елфи, през каквото се сетите, с това, че накарахте медии да посегнат на съпруга ми… Вие лично […] Аз Ви питам като човек, Вас лично – Вие съгласен ли сте с такава кампания?

Видимо обърканият Андрей Гюров, който вероятно не разбира какво има предвид опонентката му, отговаря с общи фрази в смисъл, че той и екипът му са водили позитивна кампания и не са си позволявали лични нападки. По-късно обаче, в самия край на дебата, когато вече няма възможност опонентът ѝ да реагира, Йотова се връща към темата и заявява:

Господин Гюров, моля Ви, не закачайте семейството ми. Защото разбрах, че кампанията, която проведохте срещу мен, Ви харесва и я одобрявате.

Съпругът на Илияна Йотова е в процес на възстановяване след прекарано тежко заболяване и трудно се придвижва. С твърденията си Йотова внушава, че Гюров е лично отговорен за това медии, неясно как, да посягат на мъжа ѝ и/или на цялото ѝ семейство.

Действителната история е съвсем различна. Всъщност история дори няма.

Влогърът Николай Караколев задава въпроси на Илияна Йотова и я снима, докато тя отива да гласува с мъжа си, който се придвижва с бастун. Тя охотно му отговаря, но на моменти видимо се притеснява как ще мине съпругът ѝ, и моли да му се направи път. Караколев в нито един момент от записа не се обръща към него, не му „посяга“ и не го „закача“ по никакъв начин. Може би Йотова интерпретира като посегателство срещу семейството си факта, че мъжът ѝ изобщо е сниман, но тя не отказва на Караколев интервюто.

Николай Караколев пък няма нищо общо с Андрей Гюров и неговия щаб, нито дори със симпатизантите му. Той също толкова напористо преследва и Гюров, за да му задава въпроси, освен това разпространява компромати за кандидат-вицепрезидента му Георги Кандев.

Самият Караколев реагира с ироничен коментар: „Последно кой при кого ме е пратил???“, споделяйки видео, в което наред с призива на Йотова „не закачайте семейството ми“ се показва как той обвинява Гюров и Кандев в редица грехове.

Ще се еманципира ли Йотова от Радев?

Ако предизборната кампания разкри нещо за личността на Илияна Йотова, то е, че тя много добре знае в какви случаи как да се държи, но и че не се спира пред нищо, за да постигне целите си. Друг въпрос е, че за постигането на тези цели тя с лека ръка жертва истината, а и националните интереси.

В продължение на 10 години Йотова стои в сянката на Румен Радев, излъчва безличност и търпеливо чака да дойде нейният ред. Радев продължава да се държи, все едно ѝ е шеф. Пристигайки на пресконференцията след победата ѝ на втория тур, той вървеше няколко метра пред нея – ако човек не знаеше кой е спечелил изборите, щеше да помисли, че е Радев.

Постът на премиера обаче е по-проветрив от този на президента. Президентите в България се избират веднъж на пет години, премиерите – на четири (ако изобщо изкарат пълен мандат). Министър-председателите търпят повече критика и срещу управлението им се провеждат повече протести, като в резултат на някои от тях понякога падат правителства. В България обаче не само няма случай президент да бъде свален заради обществено недоволство, ами по правило държавният глава има най-висок рейтинг сред публичните личности.

С други думи, Йотова вече е над Радев, макар той да не дава вид, че осъзнава това.

Ако премиерът продължава да се държи с нея като с подчинена, тя може да реши да покаже къде му е мястото, и между тях да настъпи разкол. Такъв сценарий едва ли би променил възгледите на президентката за геополитическата ориентация, които вероятно са по-искрено проруски от тези на Радев – все пак тя идва от средите на БСП. Но евентуално напрежение между „Дондуков“ 2 и „Дондуков“ 1 може да отслаби властта на „Прогресивна България“.

Конфронтацията между президент и премиер, дори когато са от една политическа сила, има традиция. За това допринася и конституционната роля на президента, която го позиционира като независим от партиите, помогнали му да дойде на власт.

Началото беше положено от Жельо Желев, чиято пресконференция, останала в историята като „Боянските ливади“, доведе до падането от власт на правителството на Филип Димитров. Отношенията между Иван Костов и Петър Стоянов също се обтегнаха, а кулминация на напрежението между тях беше репликата на тогавашния президент „Иване, кажи си“.

Георги Първанов нееднократно критикуваше правителството на Сергей Станишев и политиката на БСП, а след като сдаде президентския пост, основа собствена партия. Като че най-неконфликтен президент – поради мекия си нрав и липсата на политически амбиции – беше Росен Плевнелиев. Но се е случвало и той демонстративно да се разграничава от Бойко Борисов, например от проруските му залитания.

Йотова не прилича на човек с мек нрав, така че разривът между нея и Радев вероятно е въпрос на време. Дали в резултат на евентуален такъв разрив президентката би се опитала да капитализира политически факта, че е жена, е друг въпрос. Ако може да извлече дивиденти от това, без да накриви шапката на Москва, защо не?

Независимо от личността, ценностите, делата и външнополитическата ориентация на Йотова

фактът, че в България за първи път е избрана президентка, сам по себе си е добра новина.

Това означава, че в бъдеще ще е възможно и други жени да заемат този пост. Някой ден на него може да застане жена, която я е грижа за правата на жените. Само дано днешните момичета, които един ден ще могат да се кандидатират за държавен глава, да имат опит какво е да живееш в свобода и да са наясно какво означават равни права.

Experience AI begins reaching classrooms across Latin America

Post Syndicated from Saul Maldonado original https://www.raspberrypi.org/blog/experience-ai-begins-reaching-classrooms-across-latin-america/

Earlier this year, we announced that we’re expanding Experience AI, our AI literacy programme, across Latin America to bring AI education to nine more countries through support from Google.org. Working with local partner organisations, we offer Experience AI training and resources that teachers can use to enable young people to learn a foundational understanding of AI technologies, their social and ethical implications, and the role that AI can play in their lives.

Over the past few months, Experience AI launch events have already taken place in Brazil, Chile, Argentina, and Mexico. At every event, we met educators, policymakers, universities, non-profit organisations, and technology leaders and explored how AI literacy can become part of classrooms across their country. Experience AI brought us all together around a shared goal: giving teachers the confidence and resources they need to help young people understand and engage with AI critically and responsibly.

Growing the Experience AI partner network in Latin America

Across Latin America, the local organisations we are partnering with to implement Experience AI bring deep expertise in teacher professional development and education. Partners include Fundación Sadosky in Argentina, Fundación Kodea in Chile, Sincroniza Educação in Brazil, and Educación para Compartir in Mexico. 

Each partner is implementing the programme in a way that reflects its local education system and context. We work with them individually and also facilitate their collaboration around shared challenges.

A delivery model designed for lasting impact across Argentina

In Argentina, Experience AI was officially launched in June during a Google event in Buenos Aires.

Our Argentinian partner Fundación Sadosky is taking a distinctive approach to Experience AI teacher professional development by working through a network of public universities across the country, rather than relying on a central training team. Through this approach, Experience AI training will reach educators in diverse regions across the country as Fundación Sadosky builds on local expertise and existing educational networks.

Growing local capacity and developing regional trainers means Experience AI will make a lasting impact for teachers and learners, enabling high-quality AI education long after the programme’s first rollout.

The first cohort of participating universities is now working with teachers across several Argentinian provinces, before the programme expands nationwide. When fully established, Experience AI aims to support around 1,700 secondary school teachers and reach an estimated 153,000 students across Argentina.

Turning vision into action

It’s been very rewarding coming together with local partners, Google.org, universities, and education communities across Latin America around our shared vision of high-quality AI education for all young people.

After the launch events, the focus now turns to practical action: supporting teachers and bringing Experience AI into classrooms across the region. 

As the programme grows, we also look forward to working with new partners across Latin America to bring AI literacy to even more educators and young people. By 2028, we and our Latin American partners aim to support 24,000 more educators and reach more than 1.25 million young people through Experience AI.

The post Experience AI begins reaching classrooms across Latin America appeared first on Raspberry Pi Foundation.

The collective thoughts of the interwebz