Security updates for Friday

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

Security updates have been issued by AlmaLinux (cockpit-files, container-tools:rhel8, delve, gcc-toolset-12-binutils, gimp:2.8, glibc, go-toolset:rhel8, kernel, libfastjson, mariadb:10.3, mod_auth_openidc:2.3, mysql:8.0, php:8.0, pki-core:10.6 and pki-deps:10.6, squid:4, tang, tesseract, thunderbird, and virt:rhel and virt-devel:rhel), Debian (chromium, ntfs-3g, puppet-agent, and trapperkeeper-authorization-clojure), Fedora (freerdp, goose, gpsd, hatch, perl-HTTP-Headers-ActionPack, perl-MIME-tools, perl-Plack, perl-Starman, proftpd, python-mistune, ruby-build, rust-crypto-bigint, rust-ctutils, rust-elliptic-curve, rust-num-bigint, rust-num-bigint0.4, rust-num-modular, rust-num-modular0.6, rust-num-prime, rust-zmij, rust-zstd, rust-zstd-safe, rust-zstd-safe7, rust-zstd-sys, rust-zstd0.13, scribus, sofia-sip, tailscale, tor, and wordpress), Oracle (cockpit-files, delve, firefox, gimp:2.8, kernel, and osbuild-composer), Red Hat (delve, git-lfs, go-toolset:rhel8, grafana, ignition, opentelemetry-collector, osbuild-composer, python-pillow, and yggdrasil), Slackware (openssh), SUSE (bind, brotli, cpupower, expat, fuse-overlayfs, go1.26, google-guest-agent, helm, ibus-typing-booster, kernel, kyverno, libmodplug-devel, librsvg, libX11, nvidia-open-driver-G06-signed, owntone, parted, perl-Cpanel-JSON-XS, perl-Text-CSV_XS, php8, python-Brotli, regclient, roundcubemail, rsyslog, and tomcat), and Ubuntu (ca-certificates, frr, haproxy, linux-nvidia-7.0, linux-nvidia-bos, linux-nvidia-tegra, and nginx).

The post-quantum future of web privacy

Post Syndicated from Christopher Patton original https://blog.cloudflare.com/vole-mole/

The highest priorities for the transition to post-quantum cryptography are the basic building blocks of authenticated key-agreement protocols such as TLS. Without these building blocks in place, secure communication on the Internet will not be possible once cryptographically relevant quantum computers come online. However, today we rely on quantum-vulnerable cryptography for much more than TLS.

Privacy Pass is a protocol used by site operators like Cloudflare to help protect applications from abuse. One way we do this is by rate limiting individual clients so that no one client consumes too many of the site's resources. Normally this involves some combination of friction or loss of privacy for users: CAPTCHAs or other challenges to moderate traffic, along with accounts and fingerprinting to identify traffic.Privacy Pass was designed to avoid this tradeoff between friction and privacy. The basic idea is that a client gets issued a number of tokens, which they can redeem in exchange for access to the site. Crucially, each token is unlinkable to the client it was issued to, ensuring the client can use the site as they always had without sacrificing privacy.

With 10 years of deployment experience under our belts — using Privacy Pass for applications such as privacy proxies (like iCloud Private Relay) and relays (like Privacy Gateway) — we, along with others, are collaborating to bring the next generation of this technology to the web. One of our goals is to develop more sophisticated tools for managing agentic traffic that would otherwise consume too many resources and degrade performance for human visitors. Another goal is to foster a more open ecosystem by making it easier for more types of clients to participate. Achieving these goals requires developing new capabilities beyond what Privacy Pass offers today.

Given the trajectory, in this post we look at the prospects for post-quantum. In fact, we're in better shape than one might think. Privacy Pass still relies on classical cryptography, like RSA and elliptic curves. This means that a quantum attacker will be able to forge tokens at will and use them to bypass whatever security mechanism the site operator wants to implement (such as rate limiting). On the other hand, Privacy Pass is unconditionally private, meaning no attacker, quantum or not, can link the redemption of a token to its issuance. What's more, the new capabilities we're developing for this new generation of private authentication technology  can and will be instantiated in a way that upholds the same guarantee: your interaction remains private even after Q-day.

This gives us a little breathing room, but we will need an alternative soon. This is an active area of research that has made significant strides in recent years. Still, just as is the case with other aspects of the transition, the primary challenge is the sheer size of post-quantum alternatives: ML-DSA-44 signatures are a whopping 2,420 bytes, while ECDSA-P256 signatures are just 64 bytes. And there's not much hope for drop-in replacements any time soon. Just as for TLS, we'll have to settle for primitives with higher cost and re-engineer our systems to bear this cost.

But what will those primitives be? In this post, we'll explore one potential future for post-quantum privacy on the web, made possible by a recent breakthrough in the design of blind signatures.

What we need to build: a brief look at MOLE

Let's start with an overview of this new technology, which is presently called MOLE ("Moderation Of unLinkable Endorsements"). We'll have much more to say about MOLE later on, but for now we'll highlight the details that are most relevant to cryptography.

One of the core components of Privacy Pass is a blind signature scheme, which allows a client to obtain a signature under an issuer's secret key without revealing to the issuer the message that it signed. The client can then reveal the message and blind signature later on without linking the signature to its issuance.

One type of Privacy Pass token consists of the message and blindly issued signature. To verify the token, the verifier needs the issuer's public key, and so necessarily learns the identity of the issuer. Thus while these tokens protect the identity of the client, they don't protect the identity of the issuer.

Of course, this is exactly what we want for some use cases. The identity of the issuer tells us something about what type of client is connecting to our edge, a signal we use to make decisions in some of our products and for some of our customers. For instance, a client might use a token issued by one of our customers to prove it is authorized to use the customer's VPN product.

However, for many use cases, this is more information than we actually need to make a decision to grant a client access to a resource. Normally we only care that the token was issued by some entity we trust. In fact, MOLE takes this a step further: the token should hide the identity of the issuer altogether so that we can't treat tokens differently based on who issued them. This guarantees equal treatment regardless of the type of client, making it easier for more clients to participate.

This issuer-hiding property is achieved through a new object called an endorsement. An endorsement is issued by an anchor and redeemed by a moderator. Before redemption, the client and moderator agree on an anchor set, the public keys of the anchors trusted by the moderator. During redemption, the client proves it was issued an endorsement by one of the anchors in the anchor set without revealing which one. Upon acceptance, the moderator issues the client the MOLE credential it will use to moderate the client's interaction with the site.

An endorsement can take many forms, but its key property is that it can be redeemed while hiding the identity of the anchor that issued it. There will also be many types of credentials, but because they're intended to be used by a particular moderator, they needn't be anchor-hiding or even publicly verifiable. This means that everything from blind signatures to anonymous credit tokens or anonymous rate-limited credentials can be used to instantiate MOLE credentials.

Now that we have a sense of what we're building, let's look at our options for post quantum.

A feast of cryptography

When designing cryptographic protocols, adaptability and efficiency are often in tension. Sometimes we know exactly what we want to build and can tailor a construction for that purpose; but the more we tailor the protocol for that use case, the harder it becomes to adapt that construction to a different use case.

Adaptability is essential for a system like MOLE. We're not just building one kind of credential system, but many. And the types of credentials we need are likely to change over time, especially on the web where we must constantly adapt to new traffic patterns and attacker behavior. To keep up, we need a set of building blocks that can be composed together into different protocols to meet different requirements.

Most of the post-quantum cryptographic schemes in wide use today come from larger families of constructions, but have been tuned for their particular application. ML-DSA is a good example here: the cryptographic framework from which this scheme was derived can be used to build a variety of things, but to make ML-DSA as compact as possible, its parameters have been carefully tailored to build an efficient and secure digital signature scheme. However, the same parameters would not necessarily be secure for other use cases.

We have come to view this as the central challenge for post-quantum anonymous credentials: to decouple parameter selection from protocol design. Classical credential systems take this for granted: for the most part, protocol designers don't need to think about the parameters of the elliptic curve they're using, allowing even non-experts in the design of elliptic curve cryptography to build useful things with it. Unfortunately, designing efficient post-quantum credentials still requires an enormous amount of expertise.

This situation seems to have changed, however. Earlier this year, we saw a breakthrough that represents a potential sea change for anonymous credentials.

VOLE-in-the-Head

The roots of this breakthrough go back several years. We'll pick up the story three years ago, with the VOLE-in-the-Head (VOLEitH) zero-knowledge proof system (Baum et al., Crypto 2023). A zero-knowledge proof system allows one to prove knowledge of a hidden witness, satisfying some public statement while keeping the witness private. For example, a zero-knowledge proof can be used to prove knowledge of an AES key K for which Y=AES(K,X), where X,Y  are public. This proof can be transformed into a digital signature whose security reduces to the security of AES, with X,Y as the public key and K as the secret key. This is exactly the FAEST digital signature, a candidate in NIST's ongoing signature competition.

Compared to many contemporary proof systems, VOLEitH is relatively simple to understand and implement securely. VOLE stands for "Vector Oblivious Linear Evaluation" and is an interactive technique that gives two parties correlated random values. These correlations act like authentication tags, allowing the verifier to check that a computation on the hidden witness was performed correctly. In VOLEitH, the prover prepares locally what the two parties would normally generate together — hence “in the head” — then commits to those values and uses the Fiat-Shamir transformation (a widely used tool in cryptography) to select the parts the verifier checks. This step turns the interactive VOLE process into a non-interactive zero-knowledge proof.

Apart from its simplicity, VOLEitH is a fairly unremarkable proof system. It's not succinct in the way many other proof systems are: its proofs are asymptotically linear in the size of the witness and the arithmetic complexity of the statement being proved. However, VOLEitH is concretely very efficient for a particular type of statement, namely one that can be expressed as a set of equations over small binary fields.

One example is the relation Y=AES(K,X) we just discussed. We don't normally think of AES as a set of equations, but many of its computations are designed around arithmetic in GF(28), a field whose elements are single bytes. FAEST proofs for this statement are only about 4KB (NIST Round 3, 128s).

Another example is the KuMQuat signature scheme, in which the signer proves an instance of the Multivariate Quadratic (MQ) problem. Here we're given a system of random, quadratic equations of multiple variables over a small field, like GF(28). Mathematically, this MQ map P looks something like P(s) = (sTA1s + b1s,…,sTAms + bms) where s and each bi are length n vectors and each Ai is an n-by-n matrix. Given P,P(s) for random s, the MQ problem is to find s. We call it quadratic because we multiply the elements of s by itself.

The MQ problem is believed to be hard to solve even for a quantum computer. But because P is made up of quadratic equations, proving knowledge of a solution with VOLEitH is fairly cheap, yielding KuMQuat signatures as small as 2.6KB.

When compared to other post-quantum signatures like ML-DSA or FN-DSA, these numbers don't look especially impressive. But how VOLEitH compares to other schemes in a particular category of constructions is beside the point. For MOLE, we'll need to strike a balance between performance and the ability to build many types of credential systems. To that end, we need one more ingredient.

Multivariate signatures

Another way to build signatures from MQ maps involves embedding some additional mathematical structure into the map. In the Unbalanced Oil and Vinegar (UOV) signature scheme, the public key is an MQ map P, and a signature is a vector s satisfying P(s) = t, where t is obtained by hashing and salting the message to be signed.

The secret key for this signature scheme is a trapdoor for P with which the signer can derive solutions to the MQ equations. The trapdoor reveals to the signer a hidden partitioning of the variables of each quadratic equation into “oil” and “vinegar” variables. Oil variables are never multiplied by one another, so fixing the vinegar values turns the equations into a linear system that the signer can solve for the oil values. In the public key, oil and vinegar variables are mixed together in a way that hides this structure in the map.

UOV is also a candidate in NIST's ongoing signature standardization effort. It has one of the smallest signatures among the candidates, at just 135 bytes. The trade-off is that it has the largest public keys, at 46.6KB. MAYO is another multivariate candidate with much smaller public keys, at the cost of slightly larger signatures.

The key thing to take away here is that the arithmetic complexity of evaluating a UOV (or MAYO) signature is comparable to evaluating an MQ instance. Both are public quadratic maps over small binary fields, making them a good fit for VOLEitH. This brings us to the breakthrough.

Blind signatures from VOLE-in-the-Head and UOV

Earlier this year, a blind signature called PoMFRIT was published (Baum et al., USENIX Security 2026) that achieved what at the time was a record for candidate post-quantum constructions: 6.7KB for the blind signature itself and just a few hundred bytes for issuance. PoMFRIT is based on VOLE-in-the-Head and the MAYO multivariate signature. We can easily drive the size of the signature down to 4.3KB by swapping MAYO out for UOV. (This figure uses NIST round 3 parameters for UOV (uov-Ip) and FAEST-EM-128s.) The trade-off is larger public keys, but this pays off in applications where a public key can be cached and used sufficiently often.

This is competitive with state-of-the-art lattice-based constructions. But the really good news is that building blocks of PoMFRIT can easily be reconfigured into all of the credential systems we've considered for MOLE, including endorsements. More on this in a bit: for now, let's look at how PoMFRIT works in more detail.

A well-known paradigm for designing blind signatures is the following. First, the client places the message in the cryptographic equivalent of a sealed envelope, called a commitment. For our purposes, a commitment is simply the hash of the message together with some randomness generated by the client. To complete issuance, the signer simply signs the commitment directly.

To construct the blind signature, the client produces a zero-knowledge proof of knowledge of the signature and the randomness it used to compute the commitment, called the opening. A verifier would use the signer's public key to verify this proof.

Let's define a bit of notation to make this clearer:

  1. The client generates an opening r and sends a commitment c=H(m,r) to its message m to the issuer.
  2. The issuer produces a signature s=Sign(sk,c) and sends it to the client. It doesn’t learn the message as it’s hidden behind the hash.
  3. Finally, the client produces a proof π of knowledge of s,r for which Verify(pk,H(m,r))=1,

The proof π is the blind signature. It can be verified by any party in possession of the issuer's public key pk and the message m.

Unlinkability comes from the client presenting entirely different objects during the two phases: a commitment is shown to the issuer during issuance, and a zero-knowledge proof is shown to a verifier during presentation. Even if the issuer and verifier collude or are the same entity, they cannot link the sessions.

The size of the proof π is dominated by evaluation of the hash, so we need to choose a hash function that is friendly for our proof system. For most proof systems, such proof-friendly hashes are not well studied, but for VOLEitH it turns out that the Keccak permutation used in SHAKE and TurboSHAKE is a good choice. Keccak’s bitwise operations translate natively into VOLEitH constraints: XOR becomes addition, AND becomes multiplication, and rotations simply rearrange values. (Many popular SNARKs, by contrast, are designed for large prime fields, making byte- and bit-oriented operations less natural to express.)

Nevertheless, Keccak evaluations end up being the largest component of the VOLEitH proof, so we need to make sure we're using only the minimum necessary number of permutations. PoMFRIT requires two: one for the commitment and another for the signature. Concretely, the statement we prove is roughly P(s)=H(H(m,r),rs) where s is the signature, rs is a salt chosen by the issuer, P is the issuer's UOV public key, and H denotes the Keccak permutation with the output truncated to the appropriate length, which also prevents anyone from inverting.

From blind signatures to endorsements and beyond

Recall that for MOLE endorsements, we need something like a blind signature, but one that doesn't reveal the anchor that issued it. That is, we now have a sequence of anchor keys P1,…,PN, and the statement we now want to prove is  Pi(s)=H(H(m,r),rs) for some anchor key Pi whose index i is now part of the hidden witness.

With some care, we can write this as a set of constraints with roughly the same cost: two hashes and one MQ evaluation. We need to prove a bit more about the witness. What exactly? We won't spoil it for you: ZK circuit design is part of the craft of cryptographic engineering that makes it so fun. We'll just say the kind of thinking needed here is transferable to just about any modern proof system you might encounter.

Even more advanced credential systems can be constructed in this framework, including the aforementioned anonymous credit tokens and anonymous rate-limited credentials. In both of these cases, the primary cost is an additional hash or two. Each of these also requires proving that part of the witness (e.g., the credit count) is in some expected range, but this is low cost in VOLEitH.

Indeed, for every construction we have considered so far for MOLE, the primary cost is the size of the Keccak evaluation and how many times we need to evaluate it. This means that finding ways to reduce the amount of hashing yields improvements across the board.

Optimizations

Before we go any further, we need to acknowledge that cryptanalysis of multivariate cryptography is still relatively immature. We have seen advances against several parameter regimes in just the last couple of years, Both UOV and MAYO have weathered these attacks well, and an outright break of UOV and even MAYO seems more unlikely with every passing year. But we should at least expect the parameters to change in a way that adds a bit of cost to our constructions.

On the other hand, it's not uncommon for credential systems used in practice to adopt a less-than-conservative security posture for the sake of performance in so far as it affects forgery resistance. This typically means relying on stronger-than-usual computational assumptions. That is, it's possible that a (pre-quantum) attack might come along that breaks anonymous credit tokens, but not ECDSA, despite the fact that they both use the same elliptic curve.

Using fewer hashes

PoMFRIT achieved its size record by doing precisely the same thing. Recall that the blind signature requires proving two hash evaluations, one by the client and the other by the issuer. PoMFRIT observes that VOLEitH proof generation can be split into two stages. In the first stage, the client commits to a random mask. It then hashes the message normally (outside of the ZK circuit), combines the result with the mask, and sends the masked target to the issuer. The issuer uses the UOV trapdoor to find a preimage of this target. In the second stage, the client completes the proof that the preimage and previously committed mask are consistent. The hash remains part of the protocol, but the issuer — acting as the VOLEitH verifier — can compute it directly rather than requiring the zero-knowledge proof to reproduce it.

This strategy substantially reduces proof size, but it also changes our security posture. The plain UOV assumption is that no (quantum) attacker can find a pre-image for a random target without knowledge of the trapdoor. The corresponding one-more-UOV assumption (analogous to the one-more-MAYO assumption in the PoMFRIT paper) neatly captures the additional information available to the attacker as a result of this kind of optimization. The assumption, then, is that this additional information doesn't lead to an attack.

This assumption may turn out to be overly optimistic. Recently, researchers at the University of California, San Diego, and INRIA managed to forge a 1024-bit RSA signature using a Privacy Pass issuer as a signing oracle. Fortunately, Privacy Pass uses 2048-bit RSA, which, in concert with other defense mechanisms, provides a pretty good security margin. Likewise, for UOV we might consider using NIST Level 3 parameters instead of Level 1.

In any case, a bit more study will be required before we rely too heavily on these kinds of optimizations. It's worth emphasizing that a break here would only impact an attacker's ability to forge tokens, not the attacker's ability to violate a client's privacy.

Making each hash cheaper

Standard SHAKE uses a 1600-bit Keccak state with 24 applications of an underlying round function. However, since the SHA-3 standard was published, many have come to believe that 24 rounds is just too much crypto. TurboSHAKE works the same way, except the permutation uses 12 rounds instead of 24. This substantially reduces the size of VOLEitH proofs. In fact, we're quite comfortable with this security margin, and not just for this application.

Another change to Keccak that reduces the proof size is to reduce the size of the state. 256 bits of the state are reserved for the capacity to get 128 bits security. That leaves 1344 bits that can be hashed in one go, which is more than we need. Reducing the state by half to 800 bits leaves us with a rate of 544 bits, which is plenty. On top of that, it even increases the security at the same number of rounds, as an attacker has less to play with. The smaller state means we’re using half the multiplications in our circuit, which reduces the size of the proof.

Leaning into multivariate

In an ideal world, we could avoid proving conventional hashes altogether by replacing each hash with something that composes more natively with the algebraic structure of our primitives. Indeed, those familiar with Pedersen commitments and their use in elliptic curve cryptography may wonder if commitments can be constructed from multivariate cryptography.

This might look something like this: Fix public, random MQ maps F and G and commit to a message m using c=(m+F(r),G(r)). The advantage of this approach is that the degree of the constraints is the same as the degree of the constraints for the UOV signature. Not only does this make the proof smaller, it makes it far simpler, since we avoid evaluating symmetric crypto in ZK altogether.

We experimented with this approach for our application, and it yielded some impressive results. However, it's not at all clear yet if the parameter regime in which multivariate commitments yield an improvement is also secure. Notably, the risk here is not just to unforgeability, but also to client privacy. A lot more study is needed.

Another direction is to build an MQ-friendly pseudorandom generator (PRG).

For typical VOLEitH parameters, adding an extra witness bit adds ten bits to the proof. There is a neat trick to make this a lot cheaper: only one bit of proof per bit of witness! Instead of using VOLEitH directly, we commit to a (relatively) short key. That key we stretch into a larger bitstream using a PRG with low-degree so that it can be computed cheaply in the circuit. Now, to add a witness bit w, we get one extra bit k from the PRG, and store the bit w XOR k in the proof.

There is a performance trade-off: we need to compute the PRG and the witnesses start at degree 2 instead of 1. That especially increases prover time. Also the benefits on proof size only start to pay off when you need a decent number of witness bits.

And of course you need a PRG! You can create a PRG using a random MQ instance, but that’s very slow and seems overly conservative. At the other end is the Goldreich PRG, which can be seen as an as-sparse-as-possible MQ PRG. We’d want something in between, but such PRGs haven’t received much study.

Is MOLE ready for post-quantum?

We already have post-quantum privacy today, so we have some time before we need to have a solution in place, but now is the time to develop alternatives.

Multivariate cryptography looks to be a promising basis for easily building a variety of anonymous tokens and credentials. We're currently developing two schemes in this framework: VOLE-IHAT, a candidate for MOLE endorsements, and VOLE-ACT, a candidate for MOLE credentials. Our current cost estimates for these are shown in the table below. The numbers here are subject to change as we analyze and develop these constructions. We use UOV (uov-Ip) in each case, which means the public keys are all 46.6KB. VOLEitH uses the same parameters as FAEST-EM-128s:

issuance

presentation

PoMFRIT (with UOV)

<1KB

4.3KB (redemption)

VOLE-IHAT

5.6KB

6.5KB (redemption)

VOLE-ACT

5.4KB

12.0KB (spend)

These numbers are significantly larger than their classical counterparts. This comes as no great surprise, as "PQ is big" is really the main hallmark of the transition across the board. However, replacing RSA blind signatures with PoMFRIT has comparable overhead to replacing ECDSA with ML-DSA. The runtimes of these protocols are also excellent: each operation takes just a few milliseconds with our implementation. (Runtime can be improved by quite a bit, though at the cost of higher communication.)

If these numbers hold, then we've already reached an important milestone: the transition to PQ anonymous credentials for the web can now shift from cryptography design to protocol engineering. In other words, we think we can make these numbers work. For example, whereas classical blind signatures might be cheap enough to redeem on every request, we'll have to figure out how to amortize a single redemption over multiple requests.

We have some work to do before we get there. First, we need to make sure our protocols are sound, in particular by producing security proofs for them that show they are secure as long as UOV is secure. Second, we need to wait a bit for cryptanalysis of UOV to catch up. We encourage cryptographers to spend time with multivariate cryptography. Once the parameters stabilize, we believe these schemes will find a place in a ton of useful applications. We've only just scratched the surface so far.

Йотова ли спечели, или Гюров загуби?

Post Syndicated from Емилия Милчева original https://www.toest.bg/yotova-li-specheli-ili-gyurov-zagubi/

Йотова ли спечели, или Гюров загуби?

На избори обикновено се състезават обещания за по-добро бъдеще, но на балотажа за президент в България победи обещанието да не стане по-лошо. 

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

За джендъра на машините, или за активните мероприятия

Ако нещо изглежда като активно мероприятие, постига цели като активно мероприятие и отшумява лека-полека – точно както правят активните мероприятия, то по всяка вероятност е активно мероприятие. Безпомощни ли сме пред активните мероприятия, или не съвсем? От Светла Енчева.

Колко страх събра „Ганьо отива на война“?

Да си прав за агресията на Русия срещу Украйна, за европейския избор на България и за опасностите от политическото заиграване с Кремъл не означава непременно да печелиш избори. 

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

Властта успя да превърне войната на Русия срещу Украйна в риск, който уж произтича от противниците на управлението на страната. В държава членка на НАТО, на чиято територия са разследвани (руски) саботажи и която е мишена на дезинформационни и хибридни операции, управляващите представят не Русия, а политическите си противници като заплаха, по-голяма от режима на Путин. Така агресорът остана на заден план, а опасността беше приписана на онези, които му се противопоставят.

Балотажът, както е добре известно, не се печели само със собствените избиратели. Между двата тура кандидатите трябваше да търсят подкрепа извън твърдите ядра и симпатизантите си. 

Резервоарът на гласове за Йотова беше гарантиран още на първия тур от кандидатпрезидентските двойки на „Възраждане“, „Величие“ и дори МЕЧ (независимо от призива на лидера Радостин Василев да се гласува за Гюров). Третите на 25 октомври – „Възраждане“ с лидера си Костадин Костадинов и евродепутата Петър Волгин, спечелиха близо 191 000 гласа. Част от тях преминаха на втория тур към Йотова поради липса на българска Алис Вайдел. Но и наративът на Йотова и подкрепящите я е също като на лидерката на „Алтернатива за Германия“.

Forever Young. Да поговорим за възхода на „Алтернатива за Германия“

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

Неслучайни съвпадения

Противопоставянето „мир или война“ в кампанията за президент в България не е изолиран феномен. В Европа, не без помощта на Кремъл, се оформя нов политически речник, в който капитулацията се нарича мир, съпротивата – ескалация, а солидарността с нападнатия – подстрекателство към война. 

В интервю за The Economist Алис Вайдел говори с добре познати и на българското общество тези, които се налагат от управляващата „Прогресивна България“, от говорители като Явор Дачков и Мартин Карбовски, от някои социолози и анализатори, от Йотова–Вълчев, Костадинов–Волгин, „Величие“, МЕЧ и Радостин Василев. Един твърде шумен и многолик, но единогласен хор.

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

На въпрос за предполагаем руски опит за атака с дронове на летището в Лайпциг Вайдел заявява, че не е видяла доказателства за руска отговорност. Също като българските управляващи, които упорито отказват да посочат Русия като стояща зад атаките с дронове по търговски кораби в Черно море. 

Когато питат Вайдел за отговорността на Путин, тя измества разговора към президента на Украйна Зеленски. Оказва се, че нападнатата страна трябва да доказва, че иска мир. Така лидерката на германските крайнодесни се измъква от неудобни въпроси, като обръща посоката им. По същия начин действа с въпроса за дроновете – насочва разговора към предполагаемата украинска роля във взривовете на газопроводите „Северен поток“. 

„Джудо“ в комуникацията

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

В политиката обаче подобен подход може да се използва и за манипулация. Тази тактика напомня на т.нар. DARVO (от английските Deny, Attack, Reverse Victim and Offender), при която обвиненият отрича, атакува обвиняващия и разменя ролите на жертва и извършител. Вместо да отговориш на неудобния въпрос, обръщаш го срещу онзи, който го задава. Атакуваш, вместо да се защитаваш. И докато противникът се опитва да опровергае обвиненията, никой вече не помни въпроса.

Съвпадения с пропагандния речник на Кремъл се откриват в наративите на различни европейски политици. На 21 октомври The Insider разкри документи и вътрешна кореспонденция за руската операция за влияние „Допелгенгер“. От тях става ясно, че още през април 2022 г. Сергей Кириенко – първи заместник-ръководител на президентската администрация в Русия, който отговаря за вътрешнополитическите процеси, и един от най-влиятелните хора в Кремъл, поставя пред пропагандистите три задачи: да създадат „ядрена психоза“, да водят „война в името на мира“ и да преувеличават всичко. През март 2024 г. при опасения от нарастваща подкрепа за Зеленски във Франция са предложени посланията „чужда война“ и „Европа има нужда от мир“. 

А днес опити за всяване на страх от ядрена катастрофа и обещания за мир звучат и от най-високите трибуни в България.

Месец преди балотажа премиерът Румен Радев извади ядрената карта. На форум на Euronews в Брюксел на 30 септември той предупреди, че Русия може да прибегне до ядрено оръжие, ако бъде отслабена или притисната. Попита защо никой не оценява риска от опитите за конвенционална победа над най-голямата ядрена сила, и настоя да бъдат чути тревогите и на двете страни. Така заплахата, отправяна от Москва, се превърна в аргумент за сдържаност на Запада.

След първия тур Радев вече не говореше за хипотетична ядрена ескалация, а за избор между мир и война. На 26 октомври той обяви, че политическите му противници не биха се поколебали да въвлекат България във войната. За месец опасността смени адреса си: от руския ядрен арсенал към българската опозиция.

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

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

Кога и защо се разпространява манипулативното съдържание?

В последната част на поредицата Йоанна Елми изследва кога и защо се разпространява манипулативното съдържание из онлайн пространството. В текста проследяваме кризите в обществото (политически…

Технологията на внушенията беше използвана и срещу Андрей Гюров. Анализ на компанията Identrics проследява как твърдение за негов спонсор, свързан с производството на дронове в Украйна, преминава през сайтове, социални мрежи и политически говорители, докато се превърне в обвинение, че кандидатът е финансово обвързан с военната индустрия. Според анализа Мартин Карбовски също разпространява твърдението във Facebook, повтаря го на среща с граждани във Велико Търново и Илияна Йотова.

Според публикация в сайта „Гласове“ на Явор Дачков, чиято съпруга Йотова назначи за съветник в Президентството, Данчев е най-големият дарител на „Продължаваме промяната“ през 2025 г., а за президентската кампания на Андрей Гюров е предоставил общо 150 000 евро. 

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

На 29 октомври „Гласове“ публикува данни от естонски регистри, според които Петков е участвал в срещи с отбранителни институции като представител на делегация на украинския производител на бойни дронове General Cherry. Тези обстоятелства не доказват, че дарението му обвързва Гюров с военния бизнес или с каквато и да било политика на въвличане на България във войната.

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

Градската десница и изкуството да губиш избори

Първият тур на президентските избори показа, че Йотова може да бъде победена: разликата с Гюров беше под 3% и почти 43 000 гласа. Вторият тур разби надеждите. 

За Илияна Йотова гласуваха 57,6% от отишлите до урните, а за Андрей Гюров, подкрепен от „Продължаваме промяната“, „Демократична България“ и други формации от демократичната общност – 39,5%. В гласове разликата надхвърли 300 000.

Утешението е, че Гюров получи близо 750 000 гласа, една част от които са дошли от ГЕРБ. Все пак вотът е сериозен политически капитал за човек, станал широко разпознаваем благодарение на 78-те си дни като служебен премиер и обявил кандидатурата си само два месеца преди изборите. Така беше пропуснато ценно време не само за утвърждаването му като кандидат, но и за достигане до избиратели извън традиционните среди на ПП, ДБ и подкрепящите ги формации. (За сравнение, на парламентарните избори на 19 април коалицията ПП–ДБ получи 408 846 гласа, впоследствие се разпадна на двете си съставни части.)

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

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

Гюров трябваше да бъде кандидат не само на онези, които не искат Радев и Йотова, а и на хората, които нямат доверие нито на управляващите, нито на техните противници. За тях въпросът не е единствено кой е по-европейски настроен, кой е по-последователен в подкрепата за Украйна или кой има правилна позиция за съдебната власт. А защо и как един различен от управляващите президент би помогнал животът им, държавата им и бъдещето на децата им да станат по-сигурни.

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

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

Разбира се, президентът не управлява икономиката, не разпределя бюджета, не се занимава с данъците. Но има право на вето, назначава служебно правителство при определените от Конституцията условия, участва във формирането на ключови институции и може да задава политически дневен ред. Кампанията даваше възможност да се покаже как държавният глава може да бъде коректив на властта. Румен Радев го правеше непрекъснато през двата си мандата, както и чрез служебните правителства.

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

А какво следва за Андрей Гюров? Близо 750 000 гласа му дават политическа тежест, но не и автоматично политическо бъдеще. Ще остане ли лице на демократичната общност, ще потърси ли собствено място в партийния живот, или ще се оттегли отново от първата линия? 

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

Иначе тези гласове ще останат само статистика от един загубен балотаж.

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

В интервю за „Дневник“ съпредседателят на „Да, България“ Ивайло Мирчев посочва, че демократичната общност се разширява и Гюров, който е допринесъл за това, има място в нея. Чудесно, но как? Създаването на нови политически конструкции, които пренареждат едни и същи избиратели, не привлича нови.

Дълголетието на политика Йотова

През януари 2027 г. Илияна Йотова ще се закълне като седмия президент и първата жена на този пост, след като изкара 9 години като вицепрезидентка и една като действащ държавен глава. Предстои ѝ петгодишен мандат, след който Конституцията дава шанс да се пробва и за втори. 

Илияна Йотова ще се сдобие с политическо дълголетие на висок пост, по-голямо от това на лидера на ГЕРБ Бойко Борисов като трикратен премиер. Тя е единственият политик от БСП, чиято кариера, започнала още през 90-те, неизменно е била във възходящо движение – между пресцентъра на „Позитано“ 20 и позицията ѝ на „Дондуков“ 2 тя премина през столичната организация на БСП, беше депутатка и евродепутатка. Избирателите на БСП съвсем оредяха, но структурите останаха и работиха енергично за кампанията ѝ. 

Така партията се оказа в парадоксалното положение да остане извън парламента, но да има свой политик за президент – разбира се, с подкрепата на управляващата „Прогресивна България“. 

Йотова си осигури още пет години политическо бъдеще, като превърна бъдещето на България в повод за страх. Ще успее ли да предложи нещо повече?

Гласовете на Америка – брой 20

Post Syndicated from Йоанна Елми original https://www.toest.bg/glasovete-na-amerika-broy-20/

Гласовете на Америка – брой 20
* „Горна и Долна Каролина“ е игра на думи от гей жаргонa за top и bottom, кой е отгоре и кой отдолу

Гласовете на Америка – брой 20

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

Затова ето обобщение за междинните избори в САЩ накратко в десет точки. 

Всяка основна демография в САЩ се е преместила към демократите. 

Независимо дали разглеждаме населението по пол, раса, възраст или образование, Америка прави рязък завой към Демократическата партия. При мъжете под 30 години преместването вляво е с 38 пункта, при белите американци под 30-годишна възраст е с 30 пункта, а най-голям обратен завой са направили мъжете от латиноамерикански произход под 30 години – 47 пункта по-голяма подкрепа за демократите. Дори белите гласуващи без висше образование, които традиционно подкрепят Тръмп, са се преместили 14 пункта вляво. 

Гласовете на Америка – брой 20

Това е най-голямата политическа изборна победа след скандала „Уотъргейт“, заради който през 1974 и 1976 г. републиканците понасят тежко поражение. 

Демократите обръщат някогашни бастиони на републиканизма, като Канзас, който не е имал сини представители в Сената и долната камара от почти сто години насам. За последния половин век нито една партия не е вземала повече от две места, спечелени в предишни избори от опозицията с повече от 10 точки преднина. Демократите със сигурност печелят между пет и седем такива места – в Айова, Канзас, Охайо, Южна Каролина, Тексас, като Аляска и Мисури са почти преброени и сигурно също ще се обърнат в синьо. 

Гласовете на Америка – брой 20
Компилация от реакциите на политическия журналист и анализатор Стив Корнацки, превърнал се в интернет звезда. Корнацки е сред най-добрите в отразяването на изборите на живо и бе гледан от рекорден брой зрители – 29 млн. души.

Седем щата решиха изборите и ще бъдат сред ключовите за президентската кампания след две години. 

Канзас избира демократ за последен път през 1932 г. – три години след началото на Голямата депресия, когато Демократическата партия е много различна. Тексас не е бил син от 1988 г. и бе толкова сигурно републикански, че Илон Мъск се премести там, за да избяга от демократите в Калифорния.

Южна Каролина не е променяла цвета си от 2002 г. насам, Айова и Северна Каролина последно гласуват за Обама през 2008 г. Охайо беше традиционно смятан за колебаещ се щат, но оставаше непоколебимо червен през последните шест години. Това обаче може би отново ще се промени. Мейн също е колебаещ се щат с необичайно висока подкрепа за независими кандидати – този път спечелиха демократите. 

Успехът на демократите се дължи колкото на неуспеха на политиките на Тръмп – републиканците държаха президентството, долната и горната камара и имат мнозинство от консервативни съдии във Върховния съд, толкова и на смелата стратегия на Демократическата партия, която най-накрая, изглежда, осъзнава грешките си. 

Гласовете на Америка – брой 19

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

Така или иначе, без много за губене демократите инвестираха сериозни средства в кампании, насочени към места, които Тръмп бе спечелил с огромна преднина през 2024 г. На това се дължат изненадите в Канзас, Южна Каролина и Тексас. Те вероятно нямаше да бъдат толкова големи, ако войната на Тръмп в Иран не бе вдигнала цените на горивата, а хаотичните мита не бяха причината за допълнително поскъпване на живота и стоките. Блокадата на Ормузкия проток доведе не само до трусове в световната енергетика, но и смути доставките на торове, което директно се отрази на земеделците в тези щати.

Реалността надделя над театъра на сенките на идеологическите войни. 

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

Речта на преизбрания за сенатор на Джорджия Джон Ософ, сочен като един от фаворитите за кандидат-президент след две години. Пълния превод може да прочетете тук. 

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

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

В САЩ десният популизъм не доведе до мащабна промяна, а до корупция, задълбочаване на неравенствата и морален упадък. 

След края на Студената война и двете партии претърпяват промени, които отразяват разклащането на обществото: след разочарованието от ерата на Буш-младши и нахлуването в Ирак расте недоверието към институциите и медиите, което кулминира в победата на Обама – първия чернокож президент, през 2008 г.; това пък хвърля в истерия дясното и медийния му балон (добре известна е историята на Роджър Ейлс и Fox News, превърната и в популярен сериал).

По времето на Обама по-екстремните крила на републиканците бавно превземат партията, а Тръмп се появява като последен симптом на болното си време и срутва окончателно умерените фронтове вдясно. След 2000 г. неравенствата в САЩ се задълбочават, финансовата криза и войните в Близкия изток белязват обществото, животът става все по-скъп, средната класа живее все по-трудно, медийният пейзаж се фрагментира, а парите навлизат все по-безочливо в политиката. 

Клипът, с който Джош Турек обявява кандидатурата си за Сената в Айова. В него бившият баскетболист, печелил злато за страната си, разказва за заболяването си – вродена спина бифида, причината за която е излагането на баща му на хербицида „Агент Ориндж“, използван от САЩ по време на войната във Виетнам. 

Импулсът, който докарва Тръмп на власт, е популистки – той се обявява срещу институциите, системата, обещава да „изчисти блатото“ във Вашингтон. Без повече войни в Близкия изток, по-евтин живот, справедливост. Тези обещания резонират с очакванията на избирателите през 2016 г., въпреки че тогава губи популярния вот.

За завръщането му през 2024 г. пък помага тоталната немощ на демократите да изберат обединяващ кандидат, който да бъде ново лице на партията и да внесе качествени промени – вместо това на власт след пандемията бе Джо Байдън, чийто когнитивен упадък бе отричан системно от партията, преди да стане твърде очевиден. От обещанията на Тръмп обаче минаха десет години, властта никога не е била по-явно корумпирана, а всяко едно от въпросните обещания бе нарушено – не на последно място защото е невъзможно например да осъществиш масови депортации, когато икономиката на държавата ти зависи от мигрантски труд.

Може би това са първите избори, в които виждаме новото лице на демократите след тоталното им омаломощаване в годините след Обама. 

Нито Хилари Клинтън, нито Джоузеф Байдън можеха да бъдат лицето на промяната, от която има нужда страната – напротив, в очите на американците те са част от същата политическа класа, неуспяла да се справи с проблемите в зародиш. Част от привилегията на Тръмп бе именно да бъде възприеман като аутсайдер. Днес демократи като Абдул Ел-Сайeд от Мичиган също използват популистки език, само че с лява насоченост, като в една от предизборните си реклами споменава и факта, че е трябвало да се пребори със собствената си партия, за да бъде издигнат. 

Предизборна реклама на Абдул Ел-Сайед, в която се появяват баба му и дядо му. „Откъде е Абдул Ел-Сайед“, започва рекламата, имитирайки апокалиптичната и плашеща естетика, характерна за републиканския ксенофобски наратив. „Оттук, ние го отгледахме, а той ни носи покупки всяка седмица и знае кое колко струва“, разказват те. 

Макар и все още да нямаме данни за средната възраст на избраните за Камарата на представителите и Сената, със сигурност се отдалечаваме от геронтокрацията на последното десетилетие. През по-голямата част от кампанията на междинните избори прожекторите бяха върху нови лица, които често побеждаваха по-опитни членове на партията в предварителните избори, привличаха огромни публики и обещаха да променят приоритетите на демократите, щом стигнат до Вашингтон. 

Превръщат ли се САЩ в геронтокрация?

Превръща ли се лека-полека Чичо Сам в Дядо Сам и как изглежда това в контекста на предстоящите президентски избори в САЩ? Йоанна Елми продължава поредицата си за американския вот с текст за остаряването на политическата класа в САЩ.

Сред най-разпознаваемите примери са: 37-годишният Джеймс Таларико, който спечели сенаторското място в Тексас; 47-годишният Джошуа Турек от Айова; Адам Хамилтън, на 62, който обърна Канзас; 46-годишната сенаторка д-р Ани Андрюс от Южна Каролина, която победи сестрата на починалия сенатор Линдзи Греъм. Ръководството на партията положи неимоверни усилия да открие хора, които резонират с избирателите във всяка една област. А после им даде път напред, вместо да ги саботира, както ставаше през последните години.

Предизборна реклама на д-р Ани Андрюс, в която участва и баща ѝ – републиканец, гласувал за някогашната ѝ опонентка Линдзи Греъм. Д-р Андрюс набляга върху разочарованието от двете страни на политическия спектър, а баща ѝ казва, че дъщеря му със сигурност не е „луда социалистка“. 

Печели умереният, рационален, многообразен вот; въпрос на време е да разберем дали умереният, рационален, многообразен популизъм съществува и е приложим вляво. 

В кампанията на демократите осезаемо липсваха някои от по-крайните проявления на социалната политика, които им костваха избиратели през последните десет години. Д-р Андрюс например се съсредоточи върху критика към здравния министър Робърт Кенеди-младши и обвини администрацията на Тръмп за епидемията от морбили в щата си.

В своята предизборна агитация Адам Хамилтън заложи на това, че Канзас е щат в центъра на страната и се намира далеч от крайностите и поляризацията във Вашингтон. В началото на годината Хамилтън е регистриран републиканец, променя партийната си принадлежност и води кампания, основна на вярата му – Хамилтън е пастор в най-голямото методистко паство в страната. Таларико от Тексас също залага на вярата си, връщайки християнството вляво. 

Както в Камарата на представителите, така и в Сената мнозинството на демократите ще бъде многообразно – от по-левите представители, като Ел-Сайед и Трой Джаксън в Мейн, до новоизбраните демократи от традиционно консервативни щати, които могат да бъдат добър баланс или обратното – да не могат да се разбират взаимно.

Важно е да се отбележи, че мнозинството от избраните демократи са подчертано умерени и центристи. Групата по интереси на демократите Blue Dog Coalition, които поддържат центристки възгледи, обяви, че 14 нейни членове са избрани в Камарата. Други центристки групи, като New Democrats и Problem Solvers, също са увеличили представителството си.

Предизборна реклама на Джеймс Таларико, концентрирана върху достъпни цени и политически диалог за работа в името на хората

Предстоят решаващи години за републиканците. 

За повечето рационални хора беше ясно, че ерата „Тръмп“ ще има печален край, въпросът беше колко и на каква цена – както за САЩ, така и за света. Онези, които все пак понякога допускаха, че обратното е възможно, по-скоро се надяваха, че грешат за доброто на всички. В тази рубрика и преди сме си задавали въпроса какво ще се случи с партията, която избра да се идентифицира с един-единствен човек, след като неизбежните му човешки и политически провали доведат до отлив на избиратели.

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

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

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

Икономиката, състоянието на демокрацията, имиграцията, здравеопазването, външната политика и престъпността са сред приоритетите на избирателите, гласували на тези избори. Мнозинството от тях казват, че Тръмп е влошил икономическата обстановка. 38% заявяват, че са гневни относно състоянието на държавата, а 37% са недоволни. На 8 от 10 гласуващи инфлацията е причинила тежки или умерени проблеми. 74% от запитаните казват, че войната в Иран е била сред основните фактори за кого ще гласуват; 63% смятат, че е било грешка САЩ да атакуват. 

Гласовете на Америка – брой 20

Според проучване на „Галъп“ разпределението на благата и концентрацията на капитал също са сериозен проблем за избирателите. Войната на Израел в Палестина също е посочена като фактор, а вече ви разказахме за безогледните строежи на центрове за данни, които са обединяващ фактор на недоволство в идеологическия спектър. Разделенията кой какво смята за важно, са очевидни между демократи и републиканци и не на последно място са резултат от медийните балони; консервативният е доказано наситен с дезинформация, но множество крайнолеви източници също разпространяват дезинформация и/или са податливи на манипулации. 

Гласовете на Америка – брой 17

Америка сменя меката сила с тестостерон, война и показна грубост. Между кризата на мъжествеността, страха от майчинството и възхода на Китай може да се проследи как разпадът на една култура започва да пренарежда света, превръщайки крайностите в „ново нормално“ пред очите ни. От Йоанна Елми.

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

Отговорите на някои от тези въпроси ще се опитаме да дадем в следващите бюлетини. За останалото – ще покаже само времето. 

How OrderServ achieved up to 64% cost savings with multi-tenant ECS

Post Syndicated from Chetan Yewale original https://aws.amazon.com/blogs/architecture/how-orderserv-achieved-up-to-64-cost-savings-with-multi-tenant-ecs/

When your food-ordering platform doubles its brand count, dedicated clusters become your biggest cost problem, and every failed request during a traffic surge is a lost sale.

Here is how Cognizant and AWS Professional Services solved it.

Cognizant is a global services company that helps organizations modernize technology, reimagine processes, and transform customer experiences. Its OrderServ service is an omnichannel ordering solution for the food services industry that supports ordering across devices and integrates with point-of-sale, kitchen display, payment, loyalty, and other enterprise systems. Cognizant is an AWS Premier Tier Services Partner with multiple AWS Competencies and a member of the AWS Managed Service Provider (MSP) and AWS Well-Architected Partner Programs.

In 2022, Cognizant published how OrderServ 2.0 reimagined digital food ordering by migrating from a monolith to microservices on AWS Fargate, achieving 30 percent cost savings over traditional hosted architectures.

Since then, the service grew from serving a single quick-service restaurant (QSR) brand to powering multiple brands across markets. Each brand ran as a dedicated Amazon Elastic Container Service (Amazon ECS) cluster with 21 microservices. This provided hard isolation, but cost scaled linearly with every brand onboarded, and scaling speed could not keep up with promotional traffic surges that spike 5–10× within minutes.

In this post, we describe how AWS Professional Services partnered with Cognizant to transform OrderServ into a multi-tenant software as a service (SaaS) offering, achieving 47–64 percent compute cost reduction, scaling time reduced from 5–7 minutes to 30–60 seconds, and authentication costs cut by 80 percent.

The problem: Dedicated clusters don’t scale with brands

OrderServ 2.0 ran 21 microservices per brand on dedicated AWS Fargate clusters. For five brands, this meant:

  • 105 ECS services (21 × 5), each with idle capacity during off-peak hours.
  • 315 sidecar containers for observability, configuration, and log routing, duplicated per brand.
  • Linear cost growth, because onboarding a new brand required provisioning an entire cluster.
  • 5-minute scaling gap, because large container images increased image-pull and task startup times on AWS Fargate, delaying the addition of capacity during promotional traffic surges.

In QSR, every failed request during a surge is a lost sale and users may switch to competitor services immediately. The service needed to serve over 10 brands cost-effectively while handling unpredictable traffic patterns: lunch rushes, promotional events, and festival surges.

Solution overview

We addressed these challenges through four architectural changes:

  • Shared ECS cluster with a tenancy library: Application-level isolation replaces per-brand infrastructure.
  • EC2 warm pools with Bottlerocket: Sub-minute scaling replaces AWS Fargate cold starts.
  • Crash observability pipeline: Zero-loss logging and 90-day forensics at $10/month per service.
  • Passkeys for multi-tenant authentication: Biometric login reduces recurring SMS costs.

Solution 1: Shared cluster with application-level isolation

As OrderServ scaled from one to five brands, the cost of replicating 21 microservices per tenant made the economics unsustainable. We needed to consolidate infrastructure while preserving the data isolation guarantees each brand required.

Why we moved away from dedicated clusters

The dedicated-cluster model provided strong isolation but no economy of scale. With the platform growing from five brands, onboarding a new brand needed to become a configuration change, not an infrastructure provisioning exercise.

Model Pros Cons
Dedicated cluster per brand (status quo) Hard isolation, simple AWS Identity and Access Management (IAM) Linear cost, idle capacity, slow onboarding
Shared cluster with opt-out Aggregate scaling, config-only onboarding Requires application-level isolation, wider IAM scope

We chose the shared cluster as the default, with the ability to place high-volume brands on dedicated clusters when needed.

Figure 1 illustrates this transformation, from five dedicated ECS clusters (105 services, 315 sidecar containers) to a single shared cluster with 21 services and an opt-out path for high-volume brands. The tenancy library handles tenant resolution, resource routing, and context propagation, while per-tenant data stores (Amazon DynamoDB, Amazon Aurora, Valkey) maintain strict data isolation.

Evolution from dedicated clusters per brand to a shared cluster model with opt-out for high-volume brands

Figure 1: Evolution from dedicated clusters per brand to a shared cluster model with opt-out for high-volume brands

The service uses AWS Key Management Service (AWS KMS) keys to encrypt every data store at rest, and the architecture implements Transport Layer Security (TLS) to protect all service-to-service and client-to-service communication. Amazon DynamoDB automatically encrypts tables by default. Customers enable encryption when creating Amazon Aurora Clusters and the Amazon Elastic File System (Amazon EFS) file system, and customers configure both at-rest and in-transit encryption for the Amazon ElastiCache for Valkey cluster.

The tenancy library as primary isolation

Most multi-tenant architectures enforce isolation at the infrastructure level: separate accounts, separate IAM roles, or separate compute. We took a different approach: a shared .NET Core library as the primary enforcement point for tenant isolation. IAM and resource policies are the backstop that contains the blast radius when the library has a defect.

Every request carries an X-Tenant-Id header injected by the Amazon API Gateway authorizer. The tenancy library:

  • Resolves tenant context per request using request-scoped storage (AsyncLocal<T>), never static or singleton state.
  • Routes all data access: Amazon DynamoDB table names, Amazon ElastiCache for Valkey key prefixes, Amazon Aurora schema selection, and S3 paths.
  • Refuses to construct resource IDs without a tenant prefix, so a missing tenant context fails closed instead of reading another tenant’s data.
  • Propagates tenant context on service-to-service calls and asynchronous messages (SQS/SNS attributes).
  • Enriches every log line and distributed trace with the tenant ID.

This design means the same service binary runs identically in a shared cluster or a dedicated cluster. The compute model becomes a deployment decision, not an architectural constraint.

Application-level isolation moves the isolation boundary into code, and code could potentially have defects. Because an Amazon ECS task role is granted per task rather than per request, a task in the shared cluster necessarily holds permissions spanning every brand it serves. To narrow that scope, the tenancy library acquires tenant-scoped credentials at run time: it calls sts:AssumeRole with the tenant ID as a session tag, and the role’s policies reference that tag so the credentials reach only that tenant’s DynamoDB tables, S3 prefixes, and Aurora schema. Amazon ElastiCache for Valkey enforces its own layer, with per-tenant role-based access control (RBAC) users restricted to the tenant’s key pattern, so the cache engine itself refuses a cross-tenant key access rather than trusting the library to have built the key correctly.

Impact

The following table compares key operational metrics (service count, sidecar overhead, onboarding time, and capacity utilization) before and after the migration to a shared cluster model.

Metric Before (dedicated) After (shared + library)
ECS services to deploy 21 × N brands 21 total
Sidecar containers 315 (for 5 brands) 63 total
Onboarding a new brand Provision full cluster (days) Configuration change (minutes)
Idle capacity Per-brand (wasted) Aggregate (efficient)

Solution 2: EC2 warm pools with Bottlerocket for sub-minute scaling

With all brands now sharing a single cluster, traffic spikes from any one brand could impact the others. We needed a scaling strategy that could absorb sudden surges in seconds, not minutes.

Why we moved away from AWS Fargate

AWS Fargate removes infrastructure management, but OrderServ required additional capacity in under a minute during unpredictable demand surges. New tasks took 5–7 minutes to become healthy, primarily because Fargate had to download and extract the workload’s large container image before starting the application. Task provisioning, application initialization and health checks added to the delay, but image retrieval was the largest contributor. During this interval, existing ECS tasks become saturated, latency increased and some orders started failing.

The solution: EC2 Auto Scaling groups with warm pools

We migrated to Amazon EC2 Auto Scaling groups with Bottlerocket (the AWS purpose-built container OS) and warm pools:

  • The system pre-initializes and stops warm pool instances, and you pay only for Amazon Elastic Block Store (Amazon EBS) storage (~$3/month per instance).
  • When ECS needs capacity, the Auto Scaling group (ASG) starts a stopped instance (image pre-cached, ECS agent registered) in 30–60 seconds.
  • We set capacity headroom (target utilization at 80 percent), so that the first wave absorbs instantly.
  • Bottlerocket provides atomic auto-updates, eliminating the Amazon Elastic Compute Cloud (Amazon EC2) patching burden.

Five-layer scaling strategy

Rather than relying on a single scaling mechanism, we implemented five complementary layers, each targeting a specific traffic pattern to remove gaps between detection and response.

Layer Mechanism Traffic pattern solved
Predictive ECS predictive scaling (machine learning, 14-day history). Scheduled scaling for specific known events (New Year, Christmas) was already handled manually via ASG scheduled actions Daily lunch/dinner peaks, scheduled scaling
Reactive Target tracking on ALBRequestCountPerTarget (60s) Unexpected moderate spikes
Headroom EC2 ASG target capacity at 80% First wave of any spike
Downstream ECS Service Connect RequestCount metric Bottleneck shifting
Throttling API Gateway per-tenant rate limits via AWS Lambda authorizer Extreme surges (noisy neighbor)

Figure 2 illustrates how the five scaling layers work together with the EC2 warm pool. Pre-initialized warm pool instances launch in 30–60 seconds versus 5–7 minutes for an AWS Fargate cold start, at a cost of approximately $3/month per stopped instance.

Five-layer scaling strategy. Predictive scaling handles daily patterns, reactive scaling triggers warm pool activation, capacity headroom absorbs initial spikes, and per-tenant throttling protects system integrity

Figure 2: Five-layer scaling strategy

Cost and performance impact

In addition to improving scaling performance, the move from AWS Fargate to Amazon EC2 reduced the projected monthly cost of running 21 services in the Asia Pacific (Mumbai) AWS Region (ap-south-1). Two instruments do different jobs here: On-Demand Capacity Reservations is designed to make sure capacity is available in the Availability Zone when a surge activates the warm pool, and Compute Savings Plan supply the discount. The reservation carries no term commitment and can be resized or released as the fleet changes, so the following one-year and three-year terms apply to the Savings Plan alone.

Approach Monthly cost (21 services) versus AWS Fargate
AWS Fargate On-Demand (before) ~$1,568 Baseline
EC2 ASG with 1-year Compute Savings Plan and warm pool ~$832
  • ~47%
EC2 ASG with 3-year Compute Savings Plan with warm pool ~$568
  • ~64%

The reservation covers the steady-state fleet, while you stop warm pool instances, adding approximately $30 per month in Amazon EBS storage costs. Scaling time falls from 5–7 minutes to 30–60 seconds.

Solution 3: Crash observability pipeline

When containers crash in production, the support team needs three things: what happened, the root cause, and the container’s execution state at the time of failure. In the prior state, OrderServ used the awslogs driver to send container output to CloudWatch Logs. Although this captured normal application output, it did not provide durable task-stop metadata, cross-service request correlation or persistent crash artifacts.

  • Potential loss of final logs records during crash: When a task terminates abruptly, records still in the log driver’s delivery buffer might not reach Amazon CloudWatch Logs.
  • Short lived task metadata: Amazon ECS makes stopped-task information available through the API for a limited period of 1 hour, reducing the investigation window.
  • No cross-service correlation: Plain-text logs lacked trace IDs and consistent task, container, and service identifiers needed to follow a failed request across services.
  • No persistent crash artifacts: The ephemeral task storage of AWS Fargate disappeared when the task stopped, taking local crash dumps and diagnostic files with it.

The solution: FireLens sidecar + Amazon EventBridge persistence

Figure 3 shows the crash observability pipeline, where the application container emits structured JSON logs with X-Ray trace IDs to a FireLens (Fluent Bit) sidecar. The sidecar survives container termination and routes logs to CloudWatch Logs with Infrequent Access class and 30-day retention, as well as to Amazon Simple Storage Service (Amazon S3) with gzip partitioning and 365-day retention. Amazon EventBridge captures task-stop events with full metadata, while the AWS Distro for OpenTelemetry (ADOT) collector provides auto-instrumented traces to X-Ray and EFS persists crash dumps across availability zones, all at approximately $10/month per service.

Crash observability pipeline. FireLens operates at the container runtime level, surviving application container crashes. Amazon EventBridge persists task metadata for 90 days

Figure 3: Crash observability pipeline. FireLens operates at the container runtime level, surviving application container crashes. Amazon EventBridge persists task metadata for 90 days

FireLens (Fluent Bit) as a sidecar is the key architectural choice. ECS redirects the application container’s stdout at the container runtime level. If the app container receives an out-of-memory (OOM) kill, Fluent Bit still has the logs.

For hard crashes where application logs are not sufficient (stack overflow, native code fault), the .NET Core runtime automatically writes a mini dump to an Amazon EFS mount at /tmp/dumps/<container-id>. Because Amazon EFS writes are immediately durable and the mount survives container death, the process state (thread call stacks, heap objects, loaded modules) helps preserve diagnostic information after a SIGKILL. An AWS Lambda function copies dumps to S3 for analysis without VPC access. Cost: ~$0.02/month.

Amazon EventBridge to Amazon CloudWatch Logs persists the complete Amazon ECS task state change event with 90-day retention. No AWS Lambda function is required.

Every log line is structured JSON with the AWS X-Ray trace ID. The support workflow: search for an error, find the trace ID, open X-Ray, and see the full request flow across all 21 services.

We also use CloudWatch Logs Infrequent Access class with FireLens dual output (CloudWatch + S3), reducing observability costs by 62 percent per service.

Cost: approximately $10/month per service for the complete pipeline.

Solution 4: Passkeys for multi-tenant authentication

QSR mobile apps need instant login. Every second of friction is a lost order. The service previously relied on SMS one-time password (OTP) for every login, which at millions of monthly active users meant significant costs and user friction.

Passkeys with per-brand cryptographic isolation

We implemented passkeys (WebAuthn) using the native support in Amazon Cognito:

  • First-time registration: Phone number + OTP verifies identity, then the device registers a passkey bound to the Secure Enclave.
  • Every subsequent login: Face ID or fingerprint, which completes in about 2 seconds with no SMS cost.
  • New device or stale profile: Because carriers reassign phone numbers, possession of a number is treated as a claim rather than proof of identity. Registering a passkey on a new device repeats the OTP verification, and a profile whose last verification predates our revalidation window is re-verified before any registered credential is honoured.
  • Per-brand isolation: Each brand operates its own Cognito User Pool with a distinct Relying Party ID that is cryptographically isolated at the OS level.

A Post-Authentication Lambda (about 60 lines) maintains a customer authentication profile in DynamoDB, keyed by a hash of the brand/tenant id and the customer’s phone number. Because the brand ID is part of the key, the same customer registering with two brands produces two unrelated records, and the system cannot locate any record without the brand context. The profile stores only authentication state, such as which devices were registered and when each was last verified. It holds no order history, loyalty balance, or other brand-specific data. Passkey credentials are isolated by the same principle: because each brand uses a distinct Relying Party ID, the authentication flow prevents presenting a credential registered for one brand to another brand, and the device enforces that boundary. The implementation required about 95 lines of custom code to integrate with Amazon Cognito’s authentication logic.

Metric Before After
Cost per login ~$0.03 (SMS OTP) $0 (passkey)
Login latency 15–30 seconds ~2 seconds
SMS cost reduction — 80%+ at steady state
Phishing resistance None Cryptographic (device-bound)

Overall results

The architectural evolution delivered compounding savings:

Dimension Before After Improvement
Compute cost AWS Fargate On-Demand EC2 + Warm pools + ODCR + Compute Savings Plan 47–64% reduction
Scaling speed ~ 5-7 minutes 30–60 seconds 5–10× faster
Observability cost Standard CW Logs IA + FireLens + S3 62% reduction
Authentication cost SMS OTP every login Passkeys 80%+ reduction
Tenant onboarding Manual, multi-day Configuration-driven Days → minutes
Crash diagnosis “Exit Code: 1” Full trace + stack trace Blind → full visibility

For a service serving over 5 brands, the combined annual savings exceed 60 percent of the previous infrastructure cost, while simultaneously improving scaling speed, operational visibility, and user experience.

Conclusion

In this post, we showed how Cognizant OrderServ evolved from a single tenant microservices service to a multi-tenant SaaS service by making four architectural changes: shared compute with a tenancy library, Amazon EC2 warm pools for sub-minute scaling, a crash observability pipeline, and passkeys for frictionless authentication. The architecture addresses key failure modes through tenant validation, capacity headroom, per-tenant throttling and dedicated-cluster for high-volume brands. These capabilities introduce trade-offs, including greater application-level isolation, EC2 capacity management and compute Savings Plan commitments.

The key insight is that multi-tenancy does not require infrastructure isolation for every tenant. A well-designed tenancy library with strict resource-routing conventions provides application-level isolation while sharing compute, making the isolation model a deployment decision rather than an architectural constraint.

If you operate a multi-brand or multi-tenant service on Amazon ECS and face similar challenges with cost scaling or surge handling, consider these patterns:

  • Evaluate whether your isolation requirements truly need per-tenant infrastructure, or whether application-level isolation with per-tenant data stores is sufficient.
  • For workloads with unpredictable surges, compare the total cost of AWS Fargate over-provisioning against EC2 warm pools with compute Savings Plan.
  • Use FireLens sidecars for log delivery in any environment where container crashes are possible.

To learn more, explore these resources:

About the authors

Supermicro Super AI Station Review: The AI Server That Doubles as a Workstation

Post Syndicated from Ryan Smith original https://www.servethehome.com/supermicro-super-ai-station-review-the-ai-server-that-doubles-as-a-workstation/

Today we are looking at Supermicro’s Super AI Station, the company’s neat take on a DGX Station System with a design that can stand as a tower or be rackmounted as a 5U server

The post Supermicro Super AI Station Review: The AI Server That Doubles as a Workstation appeared first on ServeTheHome.

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.

The collective thoughts of the interwebz