Как да си извадим европейска здравна карта дистанционно?

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2026/ezok-gid/

Преди три години описах как може да се поръча през интернет европейска здравноосигурителна карта или ЕЗОК и да ви я доставят с куриер. Година по-рано такъв процес не съществуваше, но с упорство и няколко месеца разговори с НЗОК все пак изпълниха Закона за електронно управление и ми изкараха карта поръчана през Системата за сигурно електронно връчване.

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

Дистанционно стъпка по стъпка

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

Първо, трябва да имате предвид тези неща:

  • ЕЗОК важи за спешни случаи във всички държави на ЕС заедно с Великобритания, Исландия, Швейцария, Сърбия и Македония
  • ЕЗОК не покрива медицински транспорт, лечение и други. За целта препоръчвам да си правите допълнителни здравни осигуровки за пътуване.
  • Картите за деца важат до 5 години. За пенсионери – 10. За останалите трябва да се обновява всяка година
  • Може да заявите обновяване на карта само в рамките на месец преди изтичането на срока. Ако искате по-рано, по някаква причина трябва да подадете отделна молба за заличаване на старата карта.

Повече за тези и други условия може да прочетете на страницата на НЗОК. Повече за самата електронна услуга ще намерите тук.

След като отворите формуляра ще иска да влезете в портала на egov. Най-удобно е това да стане с ПИН на НАП, но може и с някой от електронните подписи. За съжаление, електронната идентичност все още не е осъществена на държавно ниво, най-вече заради блокиране от страна на МВР и лобизъм. Ако за пръв път влизате, може да ви иска да си направите профил, но няма нужда да въвеждате нищо освен навярно мейл адрес.

След това минавате през тези екрани. Сменяйте снимките им със стрелката надясно в галерията.

Проблемите с EGov

Най-честата грешка в работата на формуляра е, че не се появява бутонът за изпращане на генерирания документ. Тогава трябва да натиснете „Моите услуги“ както показвам горе, за да отворите списъка с вашите формуляри. Ще ви пита дали сте сигурни, защото сте щели да загубите въведеното – не е вярно, не се губи. Като натиснете бутона с молива на последния формуляр ще се отвори същата страница, но вече с бутон за изпращане. Натискате го.

Може да потвърдите, че формулярът е изпратен като отворите ССЕВ и намерите в изходящи попълнен документ към районната здравна каса.

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

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

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

През октомври ще искам пак данните на извадилите ЕЗОК през годината и начина на подаване на заявлението. Ще е интересно дали и тази година ще видим увеличение, както миналата.

Промяна при транспондерите за тол таксите в Гърция

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2026/greece-toll-2/

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

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

Затова единственият вариант остава да го вземете на място. Най-удобно за целта специално за EgnatiaPass е да го вземете още на първата тол станция след кулата. По техните инструкции като минете тол станцията Promachonas след Кулата, на първият светофар няколко стотин метра по-нататък завивате надясно се връщате по локалния път и ще намерите паркинг и будка на Egnatia точно до тол станцията. Там може да попълните документите и да получите чип. Според центъра за клиенти нямало нужда да се попълва нищо предварително през online формуляра – всичко се прави на място. На снимките долу се вижда какъв е пътя и как изглежда мястото.

Не намерих такъв център за клиенти при Маказа. Ако знаете други доставчици на такива танспондери с други удобни места за взимане или дори някои, които доставят в България – споделете.

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

Седмицата (1–6 юни)

Post Syndicated from Боряна Телбис original https://www.toest.bg/sedmitsata-1-6-yuni/

Седмицата (1–6 юни)

„Това дете няма много добър цвят, трябва да отидете веднага до болницата и да му изследвате билирубина“, ми каза Ася Демирева (която Ина Иванова ви представя в „Тези хора“), когато я бях повикала на консултация за втория ми син.

Детето беше с цвят „Тръмп“, да се разбира – жизнерадостно оранжево, с което и се изчерпваше цялата жизнерадост на ситуацията. Защото после се оказа, че лекарите имат съмнения за чернодробна недостатъчност, и бебето беше хоспитализирано в неонатологията само две седмици след раждането. Беше особен момент: занесох до входа на отделението дете, отвориха вратата, взеха ми го, затвориха вратата, после пак я отвориха, за да ми пуснат в шепите миниатюрните му дрешки и да ми кажат, че свиждането е всеки ден от 16:00 до 16:30.

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

Ася Демирева: Нашите съвършени тела
В седмицата, в която празнуваме Деня на детето, Ина Иванова разговаря с Ася Демирева за майките и божествените им тела, за живота им с бебетата и за нуждата от подкрепа по този сложен път на сливане, раздяла и въпреки това – свързаност.
Седмицата (1–6 юни)

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

От текста става ясно, че на всеки 100 исландци се пада по един доброволец от Исландската спасителна служба. Едва ли ще ви изненадам, но в България нещата не стоят точно така. Освен да си внесем исландци…

На север: Спасяването на хора в Исландия и у нас
Работата като хижарка в Исландия е причината Светла Стоянова да усвои ценни умения по оказване на първа помощ и спасяване на бедстващи хора. Сега тя ни разказва как е организирана тази животоспасяваща дейност в Исландия и в България.
Седмицата (1–6 юни)

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

Тази седмица в текста си Good night, and good luck, motherf*ckers Дарина Сарелска ни разказва за обезкървяването на легендарното американско предаване „60 минути“, кулминирало с дисциплинарното уволнение на водещия Скот Пели. „Айде няма нужда да го жалим Пели“, би казал някой – и с право. Не жалим него, а по-скоро си даваме малко по-ясна сметка (заради мащаба) какво се случва с нашите медии. Ето малка част от текста на Дарина:

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

Големите търговски оператори у нас, като част от мултинационални компании с разнородни бизнес интереси, отдавна практикуват този модел. В него телевизията е само рекламна витрина, през която се отварят (или затварят) врати към далеч по-доходоносни сделки и индустрии.

Good night, and good luck, motherf*ckers
Историята на американското предаване „60 минути“ е разказ за механизмите, чрез които се опитомяват медиите. И тези механизми са удивително сходни, независимо от пазара или знамето пред сградата на телевизията. Един текст в стил „Думам ти, дъще, сещай се, журналистическа снахо“ от Дарина Сарелска.
Седмицата (1–6 юни)

„Жива мизерия“, както каза във включване в сутрешния блок една от жителките на село Тича, чиято къща е пълна с кални наноси заради бедствието от нощта на 4 срещу 5 юни. „Жива мизерия“ потвърждавам и аз.

И като казах „бедствие“, веднага се сещам, че бюджетът на страната е в бедствено положение и Гълъб Донев ще трябва много добре да си подреди перата, за да вържем – не, но поне да приближим двата края. И това надали ще стане без надзора на Европейската комисия. За всичко това разказва Емилия Милчева в материала „Прогресът на Радев тръгва с остеритет“.

Прогресът на Радев тръгва с остеритет
Първият месец на управлението на Радев мина под знака на дефицити, неразплатени сметки и обещания за реформи. И това поставя кабинета пред труден избор: да лекува причините за кризата или просто да управлява последствията ѝ. Коментар от Емилия Милчева.
Седмицата (1–6 юни)

От бюджета минавам към буквите, по които и тази седмица се движи Зорница Христова в опит да си отговори на въпроси като: общуват ли помежду си литературните поколения; четат ли се едни други в книгите си; познават ли се изобщо? Книгите, за които ни разказва този път, са „Записано“ от Александър Шурбанов и „Тиха логика“ от Светослав Тодоров. 

По буквите: Шурбанов, Тодоров
Общуват ли помежду си литературните поколения? Четат ли се едни други в книгите си? Познават ли се изобщо? И доколко важно е това за консолидирането на съвременната литература и литературна среда? Отговорите – от Зорница Христова, която ни среща с две днешни книги.
Седмицата (1–6 юни)

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

Тоест разговаряме – епизод 10
В последния (засега) епизод на „Тоест разговаряме“ ни гостува Зорница Христова – писателка, преводачка, издателка и човек, който умее да говори за книгите така, сякаш между тях има невидими мостове.
Седмицата (1–6 юни)

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

Завършвам с текста на Теодора Станимирова, в който се разглежда въпросът защо Gen Z и Gen Alpha са все по-тревожни по отношение на климатичните промени и неизбежно някак стават по-ангажирани с климатичните политики. (То е ясно защо – за тях е въпрос на бъдеще, а за чичовците със златните рамки на очилата, дето притежават тецове и мини, е въпрос на все тая.) Чудесен материал на Теодора, в който се обяснява и защо природни бедствия като в Сливенско от тази седмица или в Габровско от миналата ще ни струват все по-скъпо – не само финансово.

Gen Z и промените в климата. Защо младите хора са все по-ангажирани със зелените политики
Как ще се почувства едно дете, ако в училище му кажат, че питейната вода на планетата ще свърши, преди да навърши 50 години? Теодора Станимирова познава усещането от личен опит. Днес тя разговаря с младежи от своето поколение, ангажирани със зелени политики, и ни разказва какво е научила.
Седмицата (1–6 юни)

В петък сутринта гледах по телевизията как една репортерка нахлува от къща в къща в същото това село Тича – без да пита може ли, само с „На живо сме“, – за да ни покаже как всичко е потънало в тиня и как хората се опитват да си изгребат живота от подовете на къщите си, макар да не е много ясно как точно ще им се помогне, като ги показваме, но нейсе… В един момент пред нея се изправи някакъв слабичък човечец, когото тя застреля с „Как ще се справите?“, все едно очакваше ей сега да ѝ излезе с презентация или даже с TED Talk как точно ще се справят.

Той обаче ѝ каза само:

Бог ще помисли за всичко.

Try the new console experience in Amazon Bedrock, optimized for Anthropic- and OpenAI-compatible APIs

Post Syndicated from Channy Yun (윤석찬) original https://aws.amazon.com/blogs/aws/try-the-new-console-experience-in-amazon-bedrock-optimized-for-anthropic-and-openai-compatible-apis/

Today, we’re announcing a new console experience in Amazon Bedrock for you to experiment, iterate, and scale with the latest AI models on Amazon Bedrock’s next-generation inference engine built for high performance, reliability, and security. This console has a refreshed workflow optimized for bedrock-mantle endpoint, which supports the latest GPT, Claude, and open-weight models with the OpenAI Responses API, OpenAI Chat Completions API, and the Anthropic Messages API.

The new console experience makes it simple to find the right model and move quickly from evaluation to production.

  • New model card – You can browse the full model catalog, compare them side by side on capabilities, modality support, context window, and applicable service quotas in a single view, removing the need to stitch together documentation, and limit calculators.
  • Project-based work – You can make a project to run evaluations and review usage insights in one streamlined workflow that mirrors the lifecycle of building a generative AI application.
  • Live documentation – You can use project-aware live documentation: code samples, SDK snippets, and API references are automatically prefilled with your project variables. You can copy a snippet straight from the console into your application and run it without modification.

How to get started
You can try a new experience by choosing Try the Bedrock Mantle Console from within the Amazon Bedrock console, or by using the new console link directly.

You can find a project-based dashboard to show inference requests and error by range of recent dates, recently used models, and the project list. You can create a project, assign models, configure API keys, and start making inference requests in minutes.

A new model catalog shows the latest GPT, Claude, and open-weight models that are supported on the bedrock-mantle engine. You can see the details of features, tokens, pricing, input/output, pricing information, and Regional availability. You can also compare up to 3 models in a single view.

When you choose the project dashboard, you can see the models used in the project, the distribution of your token usage such as total token usage, token usage per minute, inference requests per minute, and tokens per inference request. This can inform your model selection, prompt optimization, and workload consistency decisions.

You can select up to 3 models to start evaluating to compare responses side by side with the same prompt.

To build your application in the project, choose Getting started. You can migrate existing code, build a new app with the Anthropic or OpenAI SDK, or connect an AI coding assistant to Bedrock.

Choose the API & SDK, your SDK (either Anthropic or OpenAI), your preferred programming language, and your authentication method. It shows your environment code to run these in your terminal for a quick test, or save to a .env file for your application. You can also send your first request with sample code snippets to verify your setup.

When you choose Clients, you can select the AI coding agent source such as Claude Code, Cline, Codex, Cursor, or OpenCode that you want to connect to the bedrock-mantle engine. It provides instructions on how to install the AI agent, use your AWS IAM credentials or use a Bedrock API key, set environment variables, and route requests from each AI agent through Bedrock.

To learn about Anthropic- and OpenAI-compatible APIs, choose Live API docs. You can choose Anthropic API Protocol for access to Claude model features like the Messages API or OpenAI API Protocol for access to features like Responses API.

For example, when you choose OpenAI Response API, it retrieves a model response with the given model ID. These API references are automatically prefilled with the project’s selected model ID, Region, bedrock-mantle endpoint URL, and API key reference, and they update in place as you change models or settings.

You can also choose the existing Bedrock console to manage fully-managed features such as Agents, Knowledge Bases, Guardrails, fine-tuning, or the InvokeModel and Converse APIs to run on the bedrock-runtime endpoint.

Now available
The new console experience is available in all AWS Regions where the bedrock-mantle endpoint is offered: US East (N. Virginia, Ohio), US West (Oregon), Asia Pacific (Jakarta, Mumbai, Sydney, Tokyo), Europe (Frankfurt, Ireland, London, Milan, Stockholm), and South America (São Paulo). Check the full list of Regions for future updates.

Give the new console experience a try in the new Amazon Bedrock console and send feedback to AWS re:Post for Amazon Bedrock or through your usual AWS Support contacts.

Channy

Building secure B2C applications with fine-grained access control using Amazon Cognito and Amazon Verified Permissions

Post Syndicated from Sowmya Vemuri original https://aws.amazon.com/blogs/security/building-secure-b2c-applications-with-fine-grained-access-control-using-amazon-cognito-and-amazon-verified-permissions/

Modern web applications require robust security controls to protect user data and application resources. Authentication and authorization are two fundamental pillars of application security that answer critical questions: Who are you? and What are you allowed to do? Implementing these controls correctly can be challenging for developers, especially when building data-intensive applications with frameworks like Streamlit (an open-source Python framework for building interactive web applications) or when requiring fine-grained access control. Key challenges include protecting access to application resources, implementing application identity with multi-factor authentication (MFA), and implementing usage-based controls.

In this post, you will learn how to build fine-grained access controls for a sample Streamlit application using Amazon Cognito for authentication and Amazon Verified Permissions with Cedar policies for authorization. This architecture provides enterprise-grade security with minimal development effort, so you can focus on your application’s core functionality. You will learn how to reduce development time for secure applications, implement enterprise-grade authentication, through proper access management, and scale security with growing user bases.

Security architecture overview

The reference architecture follows a layered security design with four key components; separating identity verification, authorization evaluation, application logic, and enforcement boundaries. By assigning clear responsibilities to each layer, the architecture limits blast radius and ensures that a failure in any single control does not compromise the overall system.

  • Authentication layer: Amazon Cognito handles user authentication with secure credential validation and JSON web tokens (JWTs). It provides built-in password policies, account lockout protection, and session management.
  • Authorization layer: Verified Permissions uses the Cedar policy engine to evaluate fine-grained access requests based on centrally stored policies.
  • Application layer: The Streamlit frontend integrates with both services, managing user sessions and enforcing access controls in the user interface.
  • Security boundaries: Multiple layers of security controls protect against unauthorized access, privilege escalation, authentication verification, authorization checks, and input validation.

This separation of concerns enables authentication and authorization to function as complementary security controls, following defense-in-depth principles. Figure 1 illustrates the end-to-end authentication and authorization workflow, showing how a user’s sign-in request flows through Amazon Cognito for identity verification, then through Verified Permissions for Cedar policy-based access decisions, before the application enforces the result.

Figure 1: Solution architecture and workflow

Figure 1: Solution architecture and workflow

The following workflow demonstrates how the three architecture layers work together: the authentication layer (steps 1–3) handles identity verification using Amazon Cognito, the authorization layer (steps 4–6) evaluates Cedar policies using Verified Permissions, and the application layer (steps 7–8) enforces the decision in Streamlit.

  1. The user sends a sign-in request, which is submitted through Streamlit
  2. The request is authenticated by Amazon Cognito
  3. An access token is sent back to Streamlit
  4. An authorization request is sent to Verified Permissions
  5. The Cedar policy engine evaluates the request
  6. A decision is sent back by the policy engine
  7. The instruction to allow or deny is sent back to Streamlit
  8. If the instruction is to allow, access is provided

Understanding authorization with Cedar

While authentication establishes user identity, authorization determines what actions users can perform. Verified Permissions provides a scalable authorization service based on Cedar, a policy language specifically designed for fine-grained access control.

Cedar policies follow a structured format that defines who can perform which actions on what resources. Let’s examine the anatomy of a Cedar policy:

permit(
    principal == ?principal,
    action == application::Action::"ViewGrade",
    resource == ?resource
) when {
    principal has role == "Student" &&
    resource.student == principal.entityId
};

Policy components

  • Effectpermitor forbid determines whether the policy allows or denies access
  • Principal: The entity (user) making the request, represented by ?principal as a variable
  • Action: The operation being performed, scoped to your application namespace
  • Resource: The target of the action, also represented as a variable
  • Conditions: The when clause contains logical expressions that must evaluate to true

Advanced Cedar policy patterns

This section describes commonly used Cedar policy patterns for implementing fine-grained authorization with Amazon Verified Permissions. The examples illustrate how to model ownership, role-based access, hierarchical permissions, and administrative controls in real-world applications

Resource ownership control

This pattern helps ensure that users can only access resources they own:

permit(
    principal == ?principal,
    action == application::Action::"ViewGrade",
    resource == ?resource
) when {
    principal has role == "Student" &&
    resource.student == principal.entityId
};

What it does – This policy allows students to view only their own grades by:

  • Checking that the user has the Student role
  • Verifying that the grade resource’s student attribute matches the student’s entityId
  • Preventing students from accessing other students’ grades while allowing access to their own academic performance

Role-based access with resource type

This pattern grants access based on role and resource type:

permit(
    principal == ?principal,
    action == application::Action::"EditCourse",
    resource == ?resource
) when {
    principal has role == "Faculty" &&
    resource has resourceType == "Course" &&
    resource.instructor == principal.entityId
};

What it does – This policy allows faculty members to edit courses they teach by:

  • Verifying the user has the Faculty role
  • Confirming the resource is of type Course
  • Verifying that the course’s instructor attribute matches the faculty member’s entityId
  • Restricting faculty to modify only their own courses, not courses taught by other instructors

Hierarchical authorization

This pattern allows department heads to manage faculty in their department:

permit(
    principal == ?principal,
    action == application::Action::"ManageFaculty",
    resource == ?resource
) when {
    principal has role == "DepartmentHead" &&
    resource has role == "Faculty" &&
    resource.department == principal.department
};

What it does – This policy implements departmental hierarchy controls by:

  • Requiring the user to be a DepartmentHead
  • Verifying the resource is a faculty member
  • Matching the faculty member’s department with the department head’s department
  • Preventing department heads from managing faculty in other departments

Administrative override

This pattern provides emergency access with proper justification:

permit(
    principal == ?principal,
    action == ?action,
    resource == ?resource
) when {
    principal has role == "Administrator" &&
    context has emergencyAccess == true &&
    context has justification
};

What it does – This policy provides emergency access capabilities by:

  • Allowing administrators to perform any action on any resource
  • Requiring an emergency access flag to be set to true
  • Requiring a justification for emergency access
  • Supporting accountability through required documentation while enabling emergency operations

Cedar policy evaluation flow

Understanding how policies are evaluated helps design effective authorization systems. Figure 2 shows a common evaluation pattern for an academic scenario

Note: A policy match evaluates to the policy’s effect (permit or forbid). Forbid policies take precedence: if any forbid policy matches, access is denied regardless of permit policies.

Figure 2: Policy evaluation process

Figure 2: Policy evaluation process

The policy evaluation process follows these steps:

  1. User attempts to access a protected resource
  2. Application sends an authorization request to Verified Permissions
  3. Verified Permissions retrieves applicable Cedar policies from the policy store
  4. The Cedar policy engine evaluates each policy against the request
  5. If any forbid policy matches, access is denied immediately
  6. If any permit policy matches and no forbid policies match, access is allowed
  7. If no policies match, access is denied by default
  8. The evaluation result (ALLOW or DENY) is returned to the application
  9. Application enforces the authorization decision

Cedar policy language

Cedar is an Amazon open source policy language designed for fine-grained authorization. Every policy defines who (principal) can perform what action on which resource under what conditions, as shown in Figure 3.

Figure 3: Cedar policy definitions

Figure 3: Cedar policy definitions

Policy interaction

The following table shows how different policies interact in complex scenarios where multiple policies could apply:

Scenario Student policy Faculty policy Department head policy Admin policy
Student accessing own grade Permit N/A N/A Override
Faculty editing course N/A Permit N/A Override
Department head managing faculty N/A N/A Permit Override
Emergency admin access N/A N/A N/A Permit

Legend:

  • Permit – Policy allows access
  • N/A – Policy doesn’t apply
  • Override – Emergency admin access

The preceding table shows how each role’s policy applies to different scenarios, with admin access having override capabilities across most situations except for emergency admin access where it’s the primary permit authority. The Override column specifically indicates that the administrator’s emergency access policy can supersede other role-specific policies, but only when the emergencyAccess context flag is explicitly set and a justification is provided. This is not an automatic override.

Policy optimization tips:

  • Order conditions by likelihood of success – Place the most frequently true conditions first in your when clause to enable short-circuit evaluation. For example, check role before resource ownership, because role mismatches are caught earlier. See Cedar best practices.
  • Use indexed attributes for faster lookups – Use entity attributes that Verified Permissions indexes natively (entityId, role, resource type) as primary conditions. Best practices for designing an authorization model
  • Cache policy evaluations when appropriate
  • Monitor evaluation metrics and performance

Real-world application: Academic system

Consider an academic system with different user roles and their corresponding permissions:

Student: View own grades

  • Policy helps ensure students can only access grade resources where they are listed as the student
  • The policy verifies the student’s role and matches the resource owner to the principal’s entity ID

Faculty: Edit course content, manage grades

  • Policy allows faculty to edit courses they teach
  • Faculty can view and modify grades for students in their courses

Teaching assistant (TA): Grade management and course support

  • Policy permits TAs to manage grades for courses they assist with
  • Access is limited to specific courses assigned to the TA

Department head: Manage faculty assignments

  • Policy allows department heads to manage faculty in their department
  • Access is scoped to the department hierarchy

Administrator: System-wide access

  • Policy provides emergency access with proper justification
  • Administrative actions are logged and audited

Prerequisites

To implement the preceding Academic system application, you need an active AWS account, Python 3.8 or later, basic Streamlit knowledge, and AWS Identity and Access Management (IAM) permissions for Amazon Cognito and Verified Permissions.

Run the sample and extend the solution

  1. Download the code base: Start by downloading the code base from the avp streamlit samples repository
  2. Set up your development environment: Install the AWS SDK for Python (boto3) and configure your AWS credentials.
    • Install the AWS SDK for Python:
      pip install boto3
      

    • Log in to your AWS account:
      aws login --region $REGION

    • Verify that your AWS Command Line Interface (AWS CLI), Python, and dependencies are correctly configured.
      ./verify-setup.sh

  3. Create your AWS resources: Use the AWS Management Console or infrastructure as code (IaC) tools to provision your Amazon Cognito user pool and Verified Permissions policy store.
    ./deploy-demo-environment.sh
    Do you want to start the demo now? (Y/N): Y

    This provisions an Amazon Cognito user pool, a Verified Permissions policy store, and any sample resources needed for the demo.

  4. Verify the login screen:
    Figure 4: Verify login credentials

    Figure 4: Verify login credentials

  5. Demo walkthrough and shut down: Interact with the demo and test the policies and features. When you’re ready to exit, press Ctrl+C to shut down and stop.
  6. Define your Cedar policies: Start with basic policies and gradually add complexity as you understand the evaluation model.
  7. Implement authentication: Integrate Amazon Cognito authentication into your application with proper error handling.
  8. Add authorization checks: Implement authorization checks at critical access points in your application. For authentication, implement proper error handling for expired tokens, failed MFA challenges, and account lockouts. Use the Amazon Cognito built-in token refresh flow. For authorization, place Verified Permissions checks at every API endpoint and UI component that accesses protected resources.
  9. Test thoroughly: Create test scenarios for each user role and permission combination.
  10. Monitor and iterate: Set up AWS CloudTrail logging and Amazon CloudWatch alarms to monitor your security controls and refine them based on real-world usage.

Security best practices

When implementing this architecture, follow these best practices to support security:

  • Layer your security controls: Use both authentication and authorization as complementary controls rather than relying on a single mechanism.
  • Follow least privilege principles: Grant only the permissions needed for specific user roles. Start with minimal permissions and add more as needed.
  • Implement proper session management: Set appropriate token expiration and refresh policies. Amazon Cognito handles much of this automatically, but you should configure timeouts based on your security requirements.
  • Validate all inputs: Sanitize user inputs to prevent injection attacks. Don’t rely on client-side validation alone.
  • Monitor authentication events: Set up logging and alerts for suspicious activities such as repeated failed login attempts or unusual access patterns.
  • Conduct regular security reviews: Periodically audit your policies and security configurations to verify they still meet your requirements and follow current best practices.
  • Implement secure error handling: Avoid information disclosure through error messages. Provide helpful feedback to users without revealing system details that could aid attackers.

Conclusion

Implementing proper authentication and authorization is critical for application security. By using Amazon Cognito and Amazon Verified Permissions, you can build robust security controls without complex custom code. Through this approach, you can implement enterprise-grade authentication with minimal effort, define and enforce fine-grained authorization policies, scale your security controls as your application grows, and centrally manage and audit security policies.

To get started with your implementation, create your AWS resources including an Amazon Cognito user pool and Verified Permissions policy store. Define your Cedar policies based on your application’s access requirements. Integrate authentication and authorization checks into your application flow. Test thoroughly with different user roles and access scenarios. Finally, monitor and refine your security controls based on usage patterns.

For additional resources, check out the Amazon Cognito documentation and Amazon Verified Permissions documentation.

If you have feedback about this post, submit comments in the Comments section below.


Sowmya Vemuri

Sowmya Vemuri

Sowmya is a Senior Technical Customer Solutions Manager at AWS, where she partners with AWS’s largest customers to drive agentic AI transformation, cloud security strategy, and compute modernization at scale. She has 14+ years of engineering, product, and technical leadership experience building and scaling distributed systems across the stack: bare-metal servers, data platforms, enterprise and consumer applications, and autonomous cloud architectures with zero human operator access.

Weekly Metasploit Update: Apache ActiveMQ RCE, Gogs Rebase RCE, and Windows Kernel Pointer Enum

Post Syndicated from Brendan Watters original https://www.rapid7.com/blog/post/pt-metasploit-wrap-up-05-06-2026

When Open Source is a bit too Open

Several fun modules landed this week, including an Apache RCE, Windows Kernel pointer collection, and Gogs RCE via naming. Leading off is Gogs’ RCE that allows an attacker to execute commands by naming their branch –exec <command> and requesting a rebase.

Another useful post module by CharlesQuinnDev enumerates the Kernel pointers leaked via the popular NtQuerySystemInformation technique. Those exposed pointers, combined with a good write primitive, make local privilege escalation easier to accomplish. Several local privilege escalations already use that technique, so exposing just that technique was a great call!

New module content (3)

Apache ActiveMQ RCE via Jolokia addNetworkConnector

Authors: dinosn and h00die
Type: Exploit
Pull request: #21497 contributed by h00die
Path: multi/http/apache_activemq_jolokia_rce
AttackerKB reference: CVE-2026-34197

Adds a new exploit module exploit/multi/http/apache_activemq_jolokia_rce targeting CVE-2026-34197 in Apache ActiveMQ. The module abuses the Jolokia JMX-over-HTTP API exposed at /api/jolokia/ by calling the addNetworkConnector() MBean operation with a crafted brokerConfig=xbean:http://… URI. ActiveMQ fetches the attacker-controlled URL and instantiates it as a Spring XML application context, achieving remote code execution via a java.lang.ProcessBuilder bean. Authentication is required to exploit this vulnerability.

Gogs Git Rebase Argument Injection RCE

Author: Crypto-Cat
Type: Exploit
Pull request: #21515 contributed by jburgess-r7
Path: multi/http/gogs_rebase_rce

This adds an exploit module for the Gogs rebase Remote Code Execution (RCE) vulnerability. The module leverages an argument injection flaw residing in the pull request merge workflow of Gogs versions <= 0.14.2 and <= 0.15.0+dev.

Windows Kernel Pointer Exposure Enumerator

Author: CharlesQuinnDev
Type: Post
Pull request: #21039 contributed by CharlesQuinnDev
Path: windows/gather/windows_kernel_pointer_enum

Adds a new post module for Windows that enumerates kernel object pointers exposed through NtQuerySystemInformation on x64 systems. The module collects observable handle metadata and provides analysis of pointer distribution, object types, and ALPC usage, then saves the results to a CSV loot file for review. Also introduces a reusable Windows kernel handle-enumeration library.

Enhancements and features (7)

  • #20881 from h00die – This adds support for cracking Kerberos type hashes in Metasploit, specifically timeroasting, krb5tgs* and krb5asrep.
  • #21087 from jbx81-1337 – The new payloads_manager plugin lets you maintain a local archive of custom payloads and stage them into the data directory. Use the fetch or add subcommands to download or import a payload, then select to symlink it into place so it’s available to other modules. The plugin tracks each payload’s name, hash, tags, and description in a database.
  • #21412 from zeroSteiner – Updates Metasploit’s post modules to now run by default against the last opened alive session, unless explicitly specified.
  • #21429 from zeroSteiner – Removes the now redundant Linux-specific method for finding the arch so there’s a single source of truth that works in a superset of platform / session-type combinations.
  • #21488 from sjanusz-r7 – Updates HTTP login scanners to report the detected service hierarchy.
  • #21504 from h00die – Adds missing CVE references to seven existing modules: gladinet_storage_access_ticket_forge (CVE-2025-14611), cassandra_web_file_read (CVE-2020-36939), pretalx_file_read_cve_2023_28459 (CVE-2023-28459 and CVE-2023-28458), centreon_pollers_auth_rce (CVE-2019-19699), wp_responsive_thumbnail_slider_upload (CVE-2015-10144), xerte_unauthenticated_template_import_rce (CVE-2026-32985), and solarwinds_storage_manager_sql (CVE-2012-2576).
  • #21526 from zeroSteiner – Makes stability and logging improvements to the ipmi_cipher_zero, ipmi_dumphashes, and ipmi_version modules.

Bugs fixed (7)

  • #21432 from 4ravind-b – Fixes a bug in modules that invoke other modules that prevented datastore options from being validated.
  • #21448 from kx7m2qd – Fixes an issue where CIDR range filters in the addresses parameter of the db.hosts RPC endpoint were not processed correctly.
  • #21484 from zeroSteiner – Fixes python ssl command shell payloads that failed with AttributeError: module ‘ssl’ has no attribute ‘wrap_socket’.
  • #21489 from h00die – Improves the GitLab version scanner by handling additional exceptions in the scanner for non-GitLab targets and adding additional version fingerprints for real GitLab targets.
  • #21502 from h00die – Fixes a crash in the scanner/snmp/snmp_enum module when the system date was read as Null.
  • #21506 from h00die – Adds a guard clause when running uname -r in WSL startup_folder persistence.
  • #21514 from orbit-bot – Fixes a couple of references to outdated msfvenom options.

Documentation

You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro.

Scoping Out RTX Spark SFF Mini-PCs at Computex 2026

Post Syndicated from Ryan Smith original https://www.servethehome.com/scoping-out-rtx-spark-sff-mini-pcs-at-computex-2026/

While at Computex, we caught a look at some of the upcoming SFF mini-PCs based on NVIDIA’s RTX Spark SoC, including systems from ASUS, Dell, Lenovo, and MSI

The post Scoping Out RTX Spark SFF Mini-PCs at Computex 2026 appeared first on ServeTheHome.

Adding LINE Messenger to your AWS omnichannel fallback solution

Post Syndicated from Rommel Sunga original https://aws.amazon.com/blogs/messaging-and-targeting/adding-line-messenger-to-your-aws-omnichannel-fallback-solution/

In this post, you will learn how to extend an existing omnichannel fallback solution by integrating LINE Messenger, including architecture updates, deployment steps, and testing procedures. The original solution, built with Amazon API Gateway, AWS Lambda, Amazon Simple Email Service (Amazon SES), and AWS End User Messaging, delivers messages across SMS, WhatsApp, and email with automatic fallback capabilities.

For more information about the original omnichannel fallback solution that this aims to extend to LINE, see the Enhancing Message Reach: An Omnichannel Approach Using WhatsApp, SMS, and Email with AWS.

Why LINE Messenger?

LINE is a popular messaging platform in Japan, Taiwan, and Thailand, with 181 million monthly active users across its primary markets, including 100 million in Japan alone (LY Corporation FY2025 Q3 earnings data). With an 84 percent DAU/MAU ratio (88 percent in Japan), LINE sees high daily engagement, making it a reliable channel for time-sensitive communications such as appointment reminders in healthcare, order and shipping notifications in ecommerce, and promotional campaigns in retail.

While other messaging platforms are popular in specific APAC markets (KakaoTalk in South Korea, WeChat in China, Zalo in Vietnam, Viber in the Philippines), LINE holds a strong position across Japan, Taiwan, and Thailand simultaneously, making it a high-impact addition to a multi-channel messaging strategy for those countries. By adding LINE to the omnichannel fallback solution, you can reach your audience on their preferred messaging channel in these key markets. You can use LINE as either a primary or fallback channel while maintaining the same fallback and broadcast patterns already available for other channels.

Cost note: LINE Messaging API pricing varies by country and plan. See the pricing pages for LINE Messaging API, Amazon Simple Email Service (Amazon SES), and Amazon End User Messaging for details on each channel.

Architecture overview

Adding LINE to your fallback solution means you can now cover four major messaging channels from a single API endpoint, giving you broader reach without added operational complexity. The LINE integration follows the same event-driven serverless pattern as the existing channels. The following diagram shows the key additions to the architecture.

Figure 1: Updated omnichannel architecture with LINE Messenger (new components highlighted)

You can now reach LINE users with two straightforward additions to the existing architecture:

LINE Messaging API Integration – The Primary and Secondary Handler Lambda functions now include a send_line module that calls the LINE Messaging API to deliver messages using the Push Message endpoint.

AWS Secrets Manager Integration – LINE channel credentials (access token and channel secret) are stored securely in AWS Secrets Manager and retrieved by Lambda functions with caching for performance.

How LINE integration works

The LINE Messenger integration extends the existing message processing pipeline, so you get the same reliable fallback behavior that you already have for email, SMS, and WhatsApp. The following sections describe how the system handles LINE messages and fallback scenarios.

Sending a LINE message

When you send a message with LINE as the primary or fallback channel, the flow follows the same pattern as other channels with LINE-specific handling:

  1. API Gateway receives the request and places it in the Primary Amazon Simple Queue Service (Amazon SQS) Queue.
  2. The Primary Handler Lambda detects the channel as “line” and invokes the send_line module.
  3. The send_line module retrieves LINE credentials from Secrets Manager (cached for performance) and sends a request to the LINE Messaging API Push Message endpoint. The Push Message API sends messages to LINE users without requiring the user to message first. The request body contains a to field with the recipient’s LINE User ID (a unique identifier assigned when a user follows your LINE Official Account) and a messages array with the message objects to deliver. The module validates the recipient LINE User ID against the expected format (a capital ‘U’ followed by 32 lowercase hexadecimal characters) before invoking the LINE API. Requests with malformed recipient IDs are rejected early and don’t reach the external API.
  4. The Lambda function records the message status in the Amazon DynamoDB table.
  5. If fallback is configured, the Lambda function enqueues the message to the Fallback Queue. This happens regardless of whether the LINE API call succeeds (HTTP 200) or fails (non-200 response, timeout, or exception). DynamoDB records the message status as delivered on success or failed on failure. The Secondary Handler checks DynamoDB and sends through the fallback channel if the status isn’t delivered.
  6. The Secondary Handler updates the DynamoDB status to sent_fallback.

How LINE differs from other channels

Aspect Email SMS WhatsApp LINE
API Amazon SES SendEmail API AWS End User Messaging SendTextMessage API AWS End User Messaging Social SendWhatsAppMessage API LINE Messaging API Push Message API
Authentication IAM roles IAM roles IAM roles Channel access token via Secrets Manager
External Message ID Mapping Not required. SES returns the same message ID in delivery callbacks Not required. SMS returns the same message ID in delivery callbacks. Required. WhatsApp returns a different platform message ID in delivery webhooks that must be mapped back to the internal AWS message ID. Not required. No delivery callbacks exist, so no message ID correlation is needed.
Credential Storage IAM (automatic) IAM (automatic) IAM (automatic) Secrets Manager (manual)
Delivery Tracking Async via SES delivery events (SNS callback updates DynamoDB) Async via End User Messaging events (SNS callback updates DynamoDB) Async via End User Messaging events (SNS callback updates DynamoDB) None. Status set to delivered immediately on 200 response from LINE API. No delivery webhook available for LINE Messaging API.

LINE uses an external API with its own authentication rather than AWS-native IAM authentication. This means you must manage credentials through AWS Secrets Manager rather than relying on AWS Identity and Access Management (IAM)-managed authentication. For more information, see the LINE Messaging API documentation.

LINE offers two distinct messaging products for businesses, LINE Messaging API, and LINE Official Notification.

  • The LINE Messaging API, which is the focus of this guide, supports two-way conversational messaging and is widely adopted across industries for use cases such as mobile ordering, loyalty programs, and customer engagement. LINE also offers LINE Official Notification (also known as LINE Notification Messages), a separate service designed for one-way transactional notifications such as shipping updates and appointment reminders, which requires business verification.
  • LINE Official Notification provides per-message delivery completion events, but the LINE Messaging API doesn’t. With the Messaging API, an HTTP 200 response confirms LINE accepted the message for delivery, and this is the most granular delivery signal available.

Creating a LINE Messaging API Channel

You need a LINE Messaging API Channel to authenticate and send messages through the LINE integration. The following steps walk you through creating one:

  1. Sign in to the LINE Developers Console. Create a personal LINE account if you don’t have one already and download the corresponding iOS/Android/PC application. This is required to test receiving LINE messages.
  2. Create a Provider (your company/org name).
  3. Create a new Messaging API channel under that provider.
  4. After you create the channel, enable the Messaging API from the LINE Official Account Manager page.
  5. From the channel settings, note the following:
    1. Channel access token (Messaging API tab, then select Issue)

    2. Channel secret (Basic settings tab)
  6. Disable Auto-reply and Greeting messages under Messaging API settings.

Deploying and testing

The repository includes a complete deployment guide with step-by-step instructions for deploying the CDK stack, configuring LINE credentials in AWS Secrets Manager, obtaining personal LINE user IDs, and running the integration test suite. The test suite automatically detects which channels are configured and runs the applicable tests. For full deployment and testing instructions, see the Deployment Guide in the repository.

Security considerations

Before deploying this solution to production, review the following considerations and adjust for your workload and compliance obligations.

Least-privilege IAM

The Lambda execution roles in the sample scope DynamoDB, Amazon SQS, and AWS Secrets Manager permissions to specific resource ARNs. The send actions for Amazon SES (ses:SendEmail, ses:SendTemplatedEmail), SMS (sms-voice:SendTextMessage), and WhatsApp (social-messaging:SendWhatsAppMessage) are granted on resources: [“*”] in this sample for simplicity, because the specific sending identities, phone pools, and WhatsApp business accounts are left configurable. For production, scope these further where the API supports it: SES allows identity-level ARNs (for example, arn:aws:ses:region:account:identity/example.com), and End User Messaging SMS supports pool and phone-number ARNs. When adapting this code, keep resource-level scoping for everything that supports it and review the AWS Well-Architected Security Pillar and Lambda execution role guidance for production deployments.

Rotating LINE credentials

LINE channel access tokens are long-lived and are issued and rotated manually through the LINE Developers Console; there’s no programmatic rotation API. Rotate the token periodically in line with your organization’s key-rotation policy (for example, every 90 days), update the Secrets Manager secret with the new value, and force a Lambda cold start (by redeploying the stack or updating a Lambda environment variable) so the cached credentials are refreshed.

Data protection and PII retention

The solution stores message metadata and recipient identifiers (including LINE User IDs, phone numbers, and email addresses) in Amazon DynamoDB. DynamoDB uses AWS-managed encryption at rest, Secrets Manager uses AWS Key Management Service (AWS KMS), and all outbound calls to the LINE API are made over HTTPS. Point-in-time recovery is enabled on the message table.

The sample doesn’t configure a DynamoDB Time-to-Live (TTL) attribute, so records persist indefinitely. For production, add a TTL attribute (for example, expiresAt) that matches your retention policy, and review whether the RemovalPolicy.RETAIN setting on the tables is appropriate for your environment. LINE User IDs, phone numbers, and email addresses are personally identifiable information under regulations including Japan’s APPI, the EU’s GDPR, and similar laws. Assess your retention obligations, data residency requirements, and processes for handling subject access and deletion requests for the regions you serve.

Conclusion

By adding LINE Messenger to the omnichannel fallback solution, you can now reach your customers across the four messaging channels that matter most: email, SMS, WhatsApp, and LINE. The integration follows the same serverless, event-driven patterns as the existing channels, making it straightforward to deploy and maintain. LINE can serve as either a primary or fallback channel, giving you the flexibility to tailor your messaging strategy to regional preferences. As a next step, consider adding other regional messaging services to further expand your reach. You can also explore advanced LINE features such as rich messages, quick replies, and Flex Messages to create more engaging customer interactions.

Resources


About the authors

Send WhatsApp Business messages with AWS End User Messaging Social

Post Syndicated from Rommel Sunga original https://aws.amazon.com/blogs/messaging-and-targeting/send-whatsapp-business-messages-with-aws-end-user-messaging-social/

WhatsApp reaches over 3 billion monthly active users worldwide — with more than 2 billion using it every day — making it the single most direct channel for customer communication at global scale. AWS End User Messaging Social gives you a managed API to send WhatsApp Business messages without building or maintaining your own WhatsApp Business API integration.

Whether you’re building appointment reminders, order notifications, or interactive customer support flows, with WhatsApp Business messaging, you can meet customers where they already communicate.

This post is for developers and solutions architects looking to integrate WhatsApp messaging into their customer engagement workflows using AWS. By the end, you will know how to send every supported message type—from straightforward text and media to templates, interactive menus, and WhatsApp Flows—using Python and the AWS End User Messaging Social API.

Solution overview

This solution uses AWS End User Messaging Social to connect your WhatsApp Business Account (WABA) with your AWS workloads, enabling automated, two-way messaging with your customers. When a customer sends a WhatsApp message to your WABA phone number, AWS End User Messaging Social receives the message and publishes an event to an Amazon Simple Notification Service (Amazon SNS) topic. Amazon SNS then invokes an AWS Lambda function. You configure this Lambda function to process the incoming message and send a contextual WhatsApp reply to the customer. The following diagram illustrates this architecture:

Figure A: Shows the architecture flow “Customer WhatsApp → End User Messaging Social → SNS → Lambda → End User Messaging Social → Response”

IMPORTANT: Note that any WhatsApp user can send a message to your WABA number and trigger the workflow. To avoid incurring ongoing charges, complete the steps in the “Clean up” section.

The solution is deployed using the AWS Serverless Application Model (AWS SAM) and includes a sample Lambda function that demonstrates how to handle common message types, send interactive list messages, and respond with templated replies. You can extend this foundation to build more sophisticated workflows, such as invoking AWS Step Functions for multi-step processes or routing messages to container-based workloads running on AWS. AWS End User Messaging Social also provides unified billing within AWS, streamlining cost management for your WhatsApp messaging workloads.

Prerequisites

Before you run any of the examples in this post, complete the following prerequisites:

  • A phone number to link a WABA.
  • Connect a verified WhatsApp Business Account (WABA) to AWS End User Messaging Social.
  • Install the AWS SDK for Python (Boto3).
  • Optionally, install the AWS Command Line Interface (AWS CLI) for template creation (otherwise the templates must be created within the AWS Console UI or Meta’s WhatsApp Manager).
  • A phone with WhatsApp Messenger app installed to test the solution. Note that the mobile app uses a different phone number than the one that is associated with your WABA.

This walkthrough typically takes 30–45 minutes, though actual time might vary based on your familiarity with AWS services and WhatsApp Business configuration.

If you’re new to AWS End User Messaging Social, see the Getting Started with WhatsApp guide before proceeding.

IAM permissions

To configure AWS End User Messaging Social, you will need several types of permissions depending on what you’re setting up. Here are the key permissions required:

Core AWS End User Messaging social permissions

For basic configuration and management, you will need permissions for the following actions:

  • social-messaging:AssociateWhatsAppBusinessAccount — to associate a WhatsApp Business Account with your AWS account
  • social-messaging:CreateWhatsAppMessageTemplate — to create WhatsApp message templates
  • social-messaging:ListLinkedWhatsAppBusinessAccounts — to list linked WhatsApp Business Accounts
  • social-messaging:GetWhatsAppMessageTemplate — to retrieve message template details
  • social-messaging:ListWhatsAppMessageTemplates — to list message templates

For event destinations (SNS integration)

If you’re configuring event destinations with Amazon SNS, your SNS topic must have a resource policy allowing the sms-voice.amazonaws.com service principal to publish to it, and you will need an AWS Identity and Access Management (IAM) role with a trust policy allowing social-messaging.amazonaws.com to assume it. For detailed setup instructions, see Configuring Event Destinations in the AWS End User Messaging Social User Guide.

For Amazon Connect integration

If integrating with Amazon Connect, the service-linked role (SLR) includes the following permissions:

  • social-messaging:SendWhatsAppMessage
  • social-messaging:PostWhatsAppMessageMedia
  • social-messaging:GetWhatsAppMessageMedia
  • social-messaging:GetLinkedWhatsAppBusinessAccountPhoneNumber

For more information, see Amazon Connect Service-Linked Role in the Amazon Connect Administrator Guide.

Additional considerations

  • If using encrypted SNS topics with AWS KMS, you will need additional AWS Key Management Service (AWS KMS) permissions for the service to generate and decrypt data keys.

Configuration

Create a config.json file in your project directory with the following structure to store the destination WhatsApp number and the origination phone number ID (for example, phone-number-id-a1b2c3d4######) that we’re sending messages from and receiving the message:

{
    "originationPhoneNumberId": "your-whatsapp-phone-number-id",
    "destinationPhoneNumber": "+1234567890"
}

Security note: The config.json file is intended for local testing only. In production environments, avoid hardcoding phone numbers and credentials. Instead, use AWS Secrets Manager, AWS Systems Manager Parameter Store, or environment variables to manage sensitive configuration values.

Each example builds a message_data payload and sends it using the following code:

import json
import boto3
import os

config_path = os.path.join(os.path.dirname(__file__), 'config.json')
with open(config_path, 'r') as f:
    config = json.load(f)

client = boto3.client('socialmessaging')
message_data = { ... }

response = client.send_whatsapp_message(
    message=json.dumps(message_data),
    originationPhoneNumberId=config['originationPhoneNumberId'],
    metaApiVersion="v20.0"
)
print(f"Message sent successfully! Response: {response}")

For production use, wrap the send call with error handling to manage throttling and failures gracefully:

try:
    result = client.send_whatsapp_message(
        message=json.dumps(message_data),
        originationPhoneNumberId=config['originationPhoneNumberId'],
        metaApiVersion="v20.0"
    )
    print(f"Message sent. ID: {result['messageId']}")
except client.exceptions.ThrottlingException as e:
    print(f"Rate limited. Retry after backoff: {e}")
except Exception as e:
    print(f"Failed to send message: {e}")

The following sections show only the message_data for each message type. To send any of these messages, use the shared sending code from the previous Configuration section—load config.json, create the Boto3 client, and call client.send_whatsapp_message() with the payload.

Text messages

Text messages are plain text communications sent within the 24-hour conversation window. They don’t require Meta template approval and support basic formatting.

Specifications and requirements

Text messages are the foundation of WhatsApp conversations. You can send up to 4,096 characters per message. Text messages don’t require Meta approval and work within an active 24-hour conversation window that opens when a customer messages your business first, or when you initiate contact using an approved template.

  • Maximum length: 4,096 characters (including spaces and formatting)
  • 24-hour window requirement: Can only be sent within 24 hours of last customer message
  • No WhatsApp template approval required

WhatsApp message example

The following image is a WhatsApp message example.

Code example

The following is a code example for the previous message.

message_data = {
    "messaging_product": "whatsapp",
    "to": config['destinationPhoneNumber'],
    "type": "text",
    "text": {
        "body": "For the Classic T-Shirt, we recommend size Medium based on your measurements. It runs true to size with a regular fit. Size Medium: Chest 38-40 inches, Length 28 inches."
    }
}

Media messages

With Media messages, you can send images, documents, audio, and video files.

Specifications and requirements

  • Images: Maximum 5 MB (JPEG, PNG)
  • Documents: Maximum 100 MB (PDF, DOC, DOCX, PPT, PPTX, XLS, XLSX)
  • Audio: Maximum 16 MB (AAC, MP4, AMR, MP3, OGG)
  • Video: Maximum 16 MB (MP4, 3GPP)

Note: Media uploaded to Meta is retained for 30 days. If you reuse media across messages (such as a company logo), use the external URL method or re-upload before sending. The examples in this post use external URLs.

Media (document) message example

The message is presented as a PDF with the provided message body in the following example.

Code example

The following is a code example for the previous message.

message_data = {
    "messaging_product": "whatsapp",
    "to": config['destinationPhoneNumber'],
    "type": "document",
    "document": {
        "link": "https://docs.aws.amazon.com/pdfs/social-messaging/latest/userguide/social-ug.pdf",
        "caption": "\U0001F4C4 Your invoice #12345 is ready. Payment due: January 31, 2024. Questions? Reply to this message.",
        "filename": "Invoice-12345.pdf"
    }
}

Media (image) message example

This media message includes an image with a message body in the following example to describe the image. In this case it shows a laptop available for purchase with a link included as part of the message body.

Code example

The following is a code example for the previous message.

message_data = {
    "messaging_product": "whatsapp",
    "to": config['destinationPhoneNumber'],
    "type": "image",
    "image": {
            "link": "https://signin.aws.amazon.com/v2/assets/_next/static/media/[email protected]",
            "caption": "Thanks for reaching out to AnyCompany! Here's the product image for the laptop you inquired about. Feel free to reply if you need more details."
    }
}

Template messages

Template messages enable business-initiated conversations outside the 24-hour window. Templates must be created and approved by Meta before use.

Text template message creation with parameters

Template creation using CLI

While it’s possible to create templates directly in the AWS End User Messaging Social console and in WhatsApp Manager’s UI, you can also use AWS End User Messaging Social to programmatically create templates using the AWS CLI.

Step 1 — Create a file named order_confirmation_template.json in your working directory with the following template definition.

{
    "name": "order_confirmation_template",
    "language": "en",
    "category": "UTILITY",
    "parameter_format": "named",
    "components": [
      {
        "type": "HEADER",
        "format": "TEXT",
        "text": "Order {{order_number}}",
        "example": {
          "header_text_named_params": [
            {"param_name": "order_number", "example": "ORD-2025-001"}
          ]
        }
      },
      {
        "type": "BODY",
        "text": "Hi {{customer_name}},\n\nYour order has been confirmed!\n\nItem: {{item_name}}\nTotal: {{total_amount}}\nEstimated Delivery: {{delivery_date}}\n\nThank you for shopping
  with us!",
        "example": {
          "body_text_named_params": [
            {"param_name": "customer_name", "example": "John Smith"},
            {"param_name": "item_name", "example": "Wireless Headphones"},
            {"param_name": "total_amount", "example": "$179.17"},
            {"param_name": "delivery_date", "example": "November 30, 2025"}
          ]
        }
      }
    ]
  }

Step 2 — Run the following CLI command to create the template. Note that the –template-definition parameter points to the local JSON file that contains the template structure:

aws socialmessaging create-whatsapp-message-template \

    --region [AWS_REGION] \
    --cli-binary-format raw-in-base64-out \
    --id [WABA_ID] \
    
--template-definition file://order_confirmation_template.json

Template creation using the console

AWS End User Messaging Social also features a built-in template management UI which you can use to create and manage templates directly within the AWS End User Messaging Social portion of the AWS Console under AWS End User messaging > Social Messaging > Message Templates. To create a new template, choose the Create Template button.

In the first screen, you can set your template name, template language and template type for your respective WhatsApp Business Account.

In the second screen, you can set the message content for the template including variables to dynamically populate when sending the message content.

Approved message templates can be seen under the message template screen along with their approval status.

Sending the template message

After your template is approved, you can send it with parameter values populated at send time.

Important: When sending the template message, you must use the same language and locale that you used when creating the template. For example, a language code of “en” isn’t the same as “en_US”.

message_data = {
    "messaging_product": "whatsapp",
    "to": config['destinationPhoneNumber'],
    "type": "template",
    "template": {
        "name": "order_confirmation_template",
        "language": {"code": "en"},
        "components": [
            {
                "type": "header",
                "parameters": [
                    {"type": "text", "parameter_name": "order_number", "text": "ORD-2025-001"}
                ]
            },
            {
                "type": "body",
                "parameters": [
                    {"type": "text", "parameter_name": "customer_name", "text": "John Smith"},
                    {"type": "text", "parameter_name": "item_name", "text": "Wireless Headphones"},
                    {"type": "text", "parameter_name": "total_amount", "text": "$179.17"},
                    {"type": "text", "parameter_name": "delivery_date", "text": "November 30, 2025"}
                ]
            }
        ]
    }
}

Location messages

Location messages share geographic coordinates with optional name and address information. For example, you can send a location for a store branch to a customer.

Create template message with CLI

Step 1 — Create a file named store_location_template.json in your working directory with the following template definition:

{
    "name": "store_location",
    "language": "en",
    "category": "UTILITY",
    "parameter_format": "named",
    "components": [
      {
        "type": "HEADER",
        "format": "LOCATION"
      },
      {
        "type": "BODY",
        "text": "Visit our {{store_name}} store!\n\nOperating Hours: {{hours}}\n\nSee you soon!",
        "example": {
          "body_text_named_params": [
            {"param_name": "store_name", "example": "Marina Bay Store"},
            {"param_name": "hours", "example": "10 AM - 10 PM"}
          ]
        }
      }
    ]
  }

Step 2 — Run the following CLI command to create the template. The –template-definition parameter references the JSON file that you previously created:

aws socialmessaging create-whatsapp-message-template \
    --region [AWS_REGION] \
    --cli-binary-format raw-in-base64-out \
    --id [WABA_ID] \

--template-definition file://store_location_template.json

Location message example

The following image is an example of a location message.

Code example

The following is a code example of the previous location message example.

message_data = {
    "messaging_product": "whatsapp",
    "to": config['destinationPhoneNumber'],
    "type": "template",
    "template": {
        "name": "store_location",
        "language": {
            "code": "en"
        },
        "components": [
            {
                "type": "header",
                "parameters": [
                    {
                        "type": "location",
                        "location": {
                            "latitude": "1.2838",
                            "longitude": "103.8591",
                            "name": "Marina Bay Sands",
                            "address": "10 Bayfront Ave, Singapore 018956"
                        }
                    }
                ]
            },
            {
                "type": "body",
                "parameters": [
                    {
                        "type": "text",
                        "parameter_name": "store_name",
                        "text": "Marina Bay Store"
                    },
                    {
                        "type": "text",
                        "parameter_name": "hours",
                        "text": "10 AM - 10 PM"
                    }
                ]
            }
        ]
    }
}

Interactive messages

Interactive messages provide pre-defined response options through buttons or lists. These messages must be sent within the 24-hour conversation window.

  • Structured responses – Pre-defined options ensure consistent data collection
  • Enhanced UX – One-tap interactions reduce friction and improve completion rates
  • 24-hour window requirement – Must be sent within active conversation windows

Quick reply buttons message

This example demonstrates collecting guest feedback using quick reply buttons for streamlined response collection.

Technical specifications:

  • Maximum three buttons per message
  • Button text limit: 20 characters
  • Buttons appear in a horizontal row on most devices

Quick reply buttons message example

The following image is an example of the Quick reply buttons message.

Code example

The following is a code example of the previous example image.

message_data = {
    "messaging_product": "whatsapp",
    "recipient_type": "individual",
    "to": config['destinationPhoneNumber'],
    "type": "interactive",
    "interactive": {
        "type": "button",
        "body": {
            "text": "\U0001F3E8 Thank you for staying with us! How would you rate your experience?"
        },
        "action": {
            "buttons": [
                {
                    "type": "reply",
                    "reply": {
                        "id": "excellent",
                        "title": "\u2B50 \u2B50 \u2B50 \u2B50 \u2B50 Excellent"
                    }
                },
                {
                    "type": "reply",
                    "reply": {
                        "id": "good",
                        "title": "\u2B50 \u2B50 \u2B50 \u2B50 Good"
                    }
                },
                {
                    "type": "reply",
                    "reply": {
                        "id": "needs_improvement",
                        "title": "\u2B50 \u2B50 Needs Work"
                    }
                }
            ]
        }
    }
}

List Message

This example shows a restaurant menu using list messages for organized, scrollable content presentation.

Technical specifications:

  • Max Options: Up to 10 rows total, which can be organized into 10 sections.
  • Button Text: Maximum 24 characters to open the menu.
  • Sections: A list can contain multiple sections (e.g., “Starters”, “Mains”).

List message example

The following is an image of a list message example.

When the user expands the list, they can select individual items to add to their cart.

Code example

The following is the code example for the previously mentioned example.

message_data = {
    "messaging_product": "whatsapp",
    "recipient_type": "individual",
    "to": config['destinationPhoneNumber'],
    "type": "interactive",
    "interactive": {
        "type": "list",
        "body": {
            "text": "\U0001F37D\uFE0F Welcome to Bella Vista! Browse our menu categories in the following list:"
        },
        "action": {
            "button": "View Menu",
            "sections": [
                {
                    "title": "Main Courses",
                    "rows": [
                        {
                            "id": "pasta",
                            "title": "\U0001F35D Pasta Dishes",
                            "description": "Fresh pasta with signature sauces"
                        },
                        {
                            "id": "pizza",
                            "title": "\U0001F355 Wood-Fired Pizza",
                            "description": "Authentic Italian pizza"
                        }
                    ]
                },
                {
                    "title": "Beverages",
                    "rows": [
                        {
                            "id": "wine",
                            "title": "\U0001F377 Wine Selection",
                            "description": "Curated Italian wines"
                        },
                        {
                            "id": "cocktails",
                            "title": "\U0001F378 Signature Cocktails",
                            "description": "Handcrafted cocktails"
                        }
                    ]
                }
            ]
        }
    }
}

Contact messages

Contact messages share vCard-formatted contact information, useful for sharing business contact details with customers.

Contact message example

The following is an image of an example contact message.

Customers can choose to directly message the contact, save the contact to their contacts list and view details about the contact in a pop up.

Code example

The following is a code example for the previously mentioned image example.

message_data = {
    "messaging_product": "whatsapp",
    "to": config['destinationPhoneNumber'],
    "type": "contacts",
    "contacts": [
        {
            "name": {
                "formatted_name": "AnyCompany Customer Support",
                "first_name": "Customer",
                "last_name": "Support"
            },
            "org": {
                "company": "AnyCompany Inc."
            },
            "phones": [
                {
                    "phone": "+1-555-0123",
                    "type": "WORK",
                    "wa_id": "15550123"
                }
            ],
            "emails": [
                {
                    "email": "[email protected]",
                    "type": "WORK"
                }
            ],
            "urls": [
                {
                    "url": "https://www.anycompany.com",
                    "type": "WORK"
                }
            ],
            "addresses": [
                {
                    "street": "123 Business Ave",
                    "city": "Seattle",
                    "state": "WA",
                    "zip": "98101",
                    "country": "United States",
                    "country_code": "US",
                    "type": "WORK"
                }
            ]
        }
    ]
}

WhatsApp Flows

WhatsApp Flows can help power interactive experiences. Note that a verified WhatsApp Business Account is required to use WhatsApp Flows. There are two general types of WhatsApp Flows:

  • Without an endpoint — Results are stored and can be viewed directly within WhatsApp Manager. This is the type demonstrated in this post.
  • With an endpoint — Results are sent to an API endpoint that you specify for further processing.

WhatsApp Flow – survey

This is an example of a WhatsApp Flow without an endpoint that sends a product survey to customers. Since this flow doesn’t use an endpoint, the results can be viewed directly within WhatsApp Manager.

Create WhatsApp Flow using Flow Playground

First create a WhatsApp Flow using the Flows Playground on the Meta for Developers website.

You can use the following JSON in the editor to use the example flow that we’re creating.

{"version":"7.2","screens":[{"id":"QUESTION_ONE","title":"Question 1 of 2","data":{},"layout":{"type":"SingleColumnLayout","children":[{"type":"Form","name":"form","children":[{"type":"TextHeading","text":"What product categories interest you?"},{"type":"CheckboxGroup","label":"Choose all that apply:","required":true,"name":"product_categories","data-source":[{"id":"electronics","title":"Electronics"},{"id":"fashion","title":"Fashion"},{"id":"home","title":"Home & Living"},{"id":"beauty","title":"Beauty"}]},{"type":"Footer","label":"Continue","on-click-action":{"name":"navigate","next":{"type":"screen","name":"QUESTION_TWO"},"payload":{"product_categories":"${form.product_categories}"}}}]}]}},{"id":"QUESTION_TWO","title":"Question 2 of 2","data":{"product_categories":{"type":"array","items":{"type":"string"},"__example__":[]}},"terminal":true,"success":true,"layout":{"type":"SingleColumnLayout","children":[{"type":"Form","name":"form","children":[{"type":"TextHeading","text":"What's your typical budget?"},{"type":"RadioButtonsGroup","label":"Choose one:","required":true,"name":"budget_range","data-source":[{"id":"under_50","title":"Under $50"},{"id":"50_150","title":"$50 - $150"},{"id":"over_150","title":"Over $150"}]},{"type":"Footer","label":"Submit","on-click-action":{"name":"complete","payload":{"product_categories":"${data.product_categories}","budget_range":"${form.budget_range}"}}}]}]}}]}

Afterwards you will be prompted to create the template to attach to the flow.

Create WhatsApp template using AWS CLI

Step 1 — Create a file named anycompany_survey_template.json in your working directory with the following template definition. Notice that the Flow JSON is embedded directly in the flow_json field of the button component:

{ "name": "anycompany_survey", "language": "en_US", "category": "MARKETING", "components": [ { "type": "BODY", "text": "Hi! We're AnyCompany and we'd love to personalize your shopping experience. Take our quick 2-question survey!" }, { "type": "BUTTONS", "buttons": [ { "type": "FLOW", "text": "Start Survey", "flow_json": "{"version":"7.2","screens":[{"id":"QUESTION_ONE","title":"Question 1 of 2","data":{},"layout":{"type":"SingleColumnLayout","children":[{"type":"Form","name":"form","children":[{"type":"TextHeading","text":"What product categories interest you?"},{"type":"CheckboxGroup","label":"Choose all that apply:","required":true,"name":"product_categories","data-source":[{"id":"electronics","title":"Electronics"},{"id":"fashion","title":"Fashion"},{"id":"home", "title":"Home & Living"},{"id":"beauty","title":"Beauty"}]},{"type":"Footer","label":"Continue","on-click-action":{"name":"navigate","next":{"type":"screen","name":"QUESTI ON_TWO"},"payload":{"product_categories":"${form.product_categories}"}}}]}]}},{"id":"QUESTION_TWO","title":"Question 2 of 2","data":{"product_categories":{"type":"array","items":{"type":"string"},"__example__":[]}},"terminal":true,"success":true,"layout":{"type":"SingleColumnLayout
 ","children":[{"type":"Form","name":"form","children":[{"type":"TextHeading","text":"What's your typical budget?"},{"type":"RadioButtonsGroup","label":"Choose one:","required":true,"name":"budget_range","data-source":[{"id":"under_50","title":"Under $50"},{"id":"50_150","title":"$50 - $150"},{"id":"over_150","title":"Over $150"}]},{"type":"Footer","label":"Submit","on-click-action":{"name":"complete","payload":{"product_categories":"${data.product_categories}","budget_range":"${form .budget_range}"}}}]}]}}]}", "flow_action": "navigate" } ] } ] }

Step 2 — Run the following CLI command to create the template. The –template-definition parameter references the JSON file that you previously created:

aws socialmessaging create-whatsapp-message-template \
--region [AWS_REGION] \
--cli-binary-format raw-in-base64-out \
--id [WABA_ID] \
--template-definition file://anycompany_survey_template.json

Sending the WhatsApp Flow

After the Template and Flow are approved, a message can be sent with the following code.

message_data = {
    "messaging_product": "whatsapp",
    "to": config['destinationPhoneNumber'],
    "type": "template",
    "template": {
        "name": "anycompany_survey",
        "language": {
            "code": "en_US"
        },
        "components": [
            {
                "type": "button",
                "sub_type": "flow",
                "index": "0",
                "parameters": [
                    {
                        "type": "action",
                        "action": {
                            "flow_token": "survey-12345",
                            "flow_action_data": {
                                "screen": "QUESTION_ONE"
                            }
                        }
                    }
                ]
            }
        ]
    }
}

WhatsApp Flow survey example

The Flow will appear with the message body specified and a link to start the survey.

The recipient can provide their answers on each page of the Flow which can be submitted at the end.

After providing inputs, the Flow will show a completed message.

Clean up

To avoid incurring future charges, delete the resources that you created during this walkthrough:

  1. In the AWS End User Messaging Social console, disassociate (unlink) the WhatsApp Business Account.
  2. Navigate to Message Templates and delete any test templates that you created.
  3. Delete any WhatsApp Flows you created in the Flow Playground on the Meta for Developers website.
  4. Review your Amazon CloudWatch Logs for any log groups created by the service and delete them if no longer needed.
  5. Optionally, if you provisioned a phone number in End User Messaging SMS just for WhatsApp release the phone number in End User Messaging SMS.

For templates created in WhatsApp Manager, you can also delete them directly from the WhatsApp Business Manager interface on the Meta for Developers website.

Conclusion

In this post, you learned how to send various WhatsApp Business message types using AWS End User Messaging Social, including text messages, media messages, template messages, location messages, interactive messages, contact messages, and WhatsApp Flows.

AWS End User Messaging Social provides a managed API that removes the complexity of maintaining your own WhatsApp Business API integration, so you can focus on building engaging customer experiences. The service handles the heavy lifting of managing WhatsApp Business API connections, template approvals, and message delivery, while providing you with a unified, consistent API interface.

Next steps

  • Explore advanced template features with dynamic content and media headers
  • Implement webhook handlers for incoming messages and delivery receipts
  • Set up automated message flows for common customer inquiries using Amazon EventBridge
  • Integrate with Amazon Connect for omnichannel customer support experiences

We’d love to hear about your experience! Share your use cases and implementation approaches in the comments.

Additional resources


About the authors

[$] Moving beyond fork() + exec()

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

Since the earliest days of Unix, two of the core process-oriented system
calls have been fork(), which creates a child process as a copy of
the parent, and exec(), which runs a new program in the place of
the current one. In Linux kernels, those system calls are better known as
clone()
and execve(),
but the core functionality remains the same. While there is elegance to
this process-creation model, there are shortcomings as well. A recent proposal from
Li Chen to add “spawn templates” to the kernel will not be accepted in its
current form, but it may point the way toward a new process-creation
primitive in the future.

Your AI bill is out of control. Cloudflare can fix it now. 

Post Syndicated from Ming Lu original https://blog.cloudflare.com/ai-gateway-spend-limits/

There isn’t a CIO on the planet not worried about AI spend right now. CFOs are increasingly nervous, too.

For fear of falling behind, many companies have pushed their employees to use AI as aggressively as possible. The edict was clear: “Move fast, we’ll figure out the bill later.” And for the most part, it worked: AI has been genuinely transformational for the teams that leaned in.

But the costs are real: we’ve heard countless horror stories of huge bills and painful overages on token spend.

Today, we’re announcing spend controls in Cloudflare AI Gateway, and a closed beta for identity-driven budgets and routing using Cloudflare Access and your existing identity provider.

As we’ve spoken with hundreds of companies about their AI strategy, we’ve seen a common story:  The company gives every engineer access to frontier models through a shared API key. Usage takes off. At the end of the month, finance pulls the invoice and nobody can explain where the money went. Was it the machine learning team training a new pipeline? Was it an intern running Claude Opus on email triage? Was it a runaway continuous integration job that burned through 50 million tokens in a weekend? Nobody knows, because the API key doesn’t tell you who used it.

Without guidelines, staff will generally reach for the biggest model available. And why wouldn’t they? If there’s no budget, no visibility, and no routing logic, the rational move is to use the most powerful model for everything. The problem is that most tasks don’t need a frontier model. A code review summary doesn’t need the same model as a complex architecture refactor. A log parser doesn’t need the same model as a customer-facing content generator. It should be easy to select the right tool for the job, rather than defaulting to the most powerful and expensive one. And it should be simple to see where the spend is going.

You can’t calculate ROI on your AI spend without visibility on what you’re spending, and you can’t protect that ROI without controls. Every other line item in a business has a budget and per-team attribution and AI spend should be no different. 

What AI Gateway is 

AI Gateway sits between your applications and AI providers. Instead of calling OpenAI, Anthropic, Google, or any other provider directly, your requests route through AI Gateway first. 

This immediately gives you several useful tools: 

However, AI Gateway didn’t have an easy way to answer who is spending what or how you might set limits on AI spend. 

You could see aggregate usage across your account. But you couldn’t see that Jane from engineering burned through \$2,000 on Claude this month while the entire data science team only used \$400. You couldn’t set a budget that said “engineering gets \$5,000/month on frontier models, interns get \$200/month on Kimi K2.6.”

That changes today.

Spend limits: budgets for AI usage

AI Gateway now supports spend limits as a core feature. These are true cost control measures in the form of budgets set in dollars, not tokens, that track cumulative spend across all requests, operating independently of traditional rate limiting.

You can scope limits to any combination of dimensions: model, provider, or admin-defined custom attributes like user, team, or application. Windows can be fixed (resets on the first of the month, Monday, or midnight) or rolling, and set to daily, weekly, or monthly.


AI Gateway calculates cost per request based on the model’s pricing, and tracks cumulative spend against your limit in real time. You can easily track your model spend on our analytics dashboard and filter by model, provider, or any custom attribute. 

You have options for what happens when the budget limit is reached. AI Gateway will block further requests by default. Or you can set up rules through Dynamic Routes to route requests to a fallback model after you’ve hit a spend limit, so that a hard spending cap won’t kill your engineers’ workflow. We’re working to add the capability for you to also send alerts when a limit is reached. 

Spend limits are available in open beta today for all AI Gateway users across all plans. Configure them in your gateway settings in the dashboard or via the API.

We use this ourselves

We’re tracking token costs inside Cloudflare already. Every Cloudflare employee uses AI tools daily, routing millions of requests and billions of tokens per month through AI Gateway. We faced the same question every company faces at this scale: who’s using what, and how do we budget for it?

We solved this by enabling AI Gateway to add identity to every request. When an employee authenticates via Cloudflare Access, we extract their identity from the JSON Web Token (JWT) and attach it as metadata on the AI Gateway request. This makes per-user token consumption, team-level usage breakdowns, and cost attribution across the organization all visible in one place.

Identity-driven budgets and policies (closed beta)

In addition to spend limits, today we’re also announcing identity-driven budgets and policies as a closed beta. 

Spend limits in AI Gateway let you set budgets by model, provider, or custom attributes. But your application has to pass that metadata, and AI Gateway trusts whatever it receives. For verified, automatic attribution, you need identity.

When combined with Cloudflare Access, AI Gateway can see who is making each request — not just which account, but which employee, which identity provider (IdP) group, which service, etc.

Here’s what that looks like in practice.



You can set per-user budgets, say \$500/month for individual contributors and \$2,000 for senior engineers. When a user hits their limit, requests can be downgraded to a cheaper model or blocked.

You can set per-team model policies. For instance, your ML team gets Claude Opus and GPT-4o. The brand design team can access generative image and video models. Interns use open-source models on Workers AI. These policies map directly to your existing IdP groups, the same identity provider groups you already manage.

For CI/CD pipelines and autonomous agents, Access service tokens allow you to give each agent a named identity. You can see that your code review bot used 5 million tokens this week while your documentation generator used 500,000. If one agent is running out of control, apply a budget policy without affecting any others.

Every AI Gateway log entry will include the authenticated identity: email, IdP group, service token name. Export these to your analytics platform, and you’ve got a cost-by-user-by-team breakdown without building anything custom.

Under the hood, you create a Cloudflare Access application for your AI Gateway endpoint and configure policies based on your IdP groups. When a developer or agent makes a request, they authenticate via OAuth, using the typical CLI device-code flow. AI Gateway validates the token and extracts the identity. You don’t need to write a custom Worker, parse JWTs yourself, or rely on honor-system metadata headers.

We recently wrote about how we built our internal AI engineering stack. This is what we are making available today — so you can use it, too, and you don’t have to build it yourself.

If you would like access to the closed beta, sign up here

What’s next: from cost control to cost optimization

Setting a budget is necessary. But once you’ve got a budget, how do you make the most of it? 

The reality is that not every request needs a frontier model: a summarization task can run on a smaller, cheaper model without meaningful quality loss, while a large-scale code refactor might require the bleeding edge. But without controls, people will almost always opt for the most advanced model.

A solution for that is coming next: We’re building intelligent, task-based routing in AI Gateway. For each request, we can analyze and automatically route it to the model that will give you the best result at the lowest cost. This is in active development, so follow our developer docs and changelog

Get started

It’s free to get started with AI Gateway. Spend limits are available now for all users.

If you haven’t already, create a gateway and point your applications at it. From there, set up spend limits in the dashboard or via API. Start with a high limit in monitoring mode to understand your current usage patterns before you start enforcing.

If you want per-user attribution and team-based policies, sign up for the identity-driven budgets closed beta, and we’ll get you set up with the Access integration.

We want to hear how you’re managing AI costs today. Join the conversation on Cloudflare Community or reach out to discuss your broader AI security strategy.

Ruby’s Bundler adds a cooldown feature

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

Version
4.0.13
of Ruby’s Bundler
package-manager has added
dependency cooldowns
in order to help mitigate the effect of
supply-chain attacks:

Most supply-chain attacks against RubyGems exploit a narrow window:
an account is compromised, a malicious version ships, and any
bundle install in the minutes that follow resolves
straight to it. Bundler 4.0.13 introduces cooldown, a time-based
filter that refuses to resolve to a version until it has been public
for at least N days. Releases too new to have been scrutinized are
passed over in favor of ones that have aged past the window.

The feature was designed in
the open
, drawing on how
other ecosystems approach the same problem
. It is opt-in, and
complements rather than replaces existing defenses like mandatory 2FA
and trusted publishing.

LWN covered
dependency cooldowns in April, and the takeover of RubyGems and
Bundler
in October 2025.

Security updates for Friday

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

Security updates have been issued by AlmaLinux (kernel), Debian (dovecot, exim4, frr, and haveged), Fedora (cockpit, freeipa, jpegxl, libre, nextcloud, perl-Cpanel-JSON-XS, perl-Crypt-Argon2, perl-Dist-Build, perl-ExtUtils-Builder, perl-ExtUtils-Builder-Compiler, perl-HTTP-Tiny, perl-libwww-perl, python-starlette, rubygem-yard, rust-sequoia-cert-store, rust-sequoia-chameleon-gnupg, rust-sequoia-octopus-librnp, rust-sequoia-sop, rust-sequoia-sq, rust-sequoia-wot, samba, and transmission), Red Hat (image-builder), Slackware (dnsmasq and libinput), SUSE (evince, glibc, google-guest-agent, hplip, ignition, LibVNCServer, libzypp, libsolv, python-Pillow, salt, thunderbird, and vim), and Ubuntu (apache2, linux, linux-aws, linux-aws-5.15, linux-aws-fips, linux-fips, linux-gcp,
linux-gcp-5.15, linux-gcp-fips, linux-gke, linux-gkeop, linux-hwe-5.15,
linux-ibm, linux-ibm-5.15, linux-intel-iot-realtime, linux-intel-iotg,
linux-kvm, linux-nvidia, linux-nvidia-tegra, linux-nvidia-tegra-5.15,
linux-nvidia-tegra-igx, linux-oracle, linux-raspi, linux-realtime, linux, linux-aws, linux-aws-fips, linux-azure, linux-azure-5.4,
linux-azure-fips, linux-bluefield, linux-fips, linux-gcp, linux-gcp-5.4,
linux-gcp-fips, linux-iot, linux-kvm, linux-oracle, linux-oracle-5.4,
linux-xilinx-zynqmp, linux, linux-azure, linux-azure-4.15, linux-azure-fips, linux-fips,
linux-gcp-4.15, linux-gcp-fips, linux-kvm, linux-oracle, linux-aws-5.4, linux-hwe-5.4, linux-azure-fips, linux-fips, linux-raspi, linux-raspi-5.4, nano, postfix, robocode, tomcat6, tomcat7, and yard).

The collective thoughts of the interwebz