Post Syndicated from The Atlantic original https://www.youtube.com/shorts/-5PkGdQRbdE
AI-powered performance recommendations for Amazon Redshift
Post Syndicated from Steve Phillips original https://aws.amazon.com/blogs/big-data/ai-powered-performance-recommendations-for-amazon-redshift/
Data platform teams running Amazon Redshift collect performance telemetry across system views like SYS_QUERY_HISTORY, SVV_TABLE_INFO, and SVV_ALTER_TABLE_RECOMMENDATIONS, plus Amazon CloudWatch metrics for capacity, query execution, and storage. The challenge is interpretation. Correlating a spike in QueryRuntimeBreakdown commit time with hundreds of small INSERT statements, or connecting high disk spill with undersized compute, takes deep expertise and hours of manual analysis.
In this post, you learn how to build an AI-powered solution that collects the telemetry, pre-computes performance signals, correlates them with CloudWatch, and uses Amazon Bedrock to generate prioritized recommendations. The source code is in the accompanying GitHub repository: sample-ai-performance-advisor-for-amazon-redshift.
The signal-based design is what makes this solution produce precise recommendations rather than generic advice. Instead of dumping raw system view output into the large language model (LLM) prompt, the collector pre-computes boolean and threshold-based findings, pairs them with CloudWatch correlations, and hands the model a structured context. The model then cross-references specific query IDs, table names, and metric values in its output.
Solution overview
Two AWS Lambda functions run on a 24-hour Amazon EventBridge schedule:
- The collector Lambda runs 13 diagnostic SQL queries against Amazon Redshift Serverless and reads the workgroup’s Workload Management (WLM) configuration. It also collects CloudWatch metrics across capacity, query execution, WLM, connections, and storage. From these inputs, it computes the performance signals. Finally, it writes a telemetry JSON file to Amazon Simple Storage Service (Amazon S3).
- The analyzer Lambda reads the telemetry from Amazon S3, builds a structured prompt with inline CloudWatch-to-signal correlations. Using the correlations, the analyzer calls Amazon Bedrock (Anthropic Claude Sonnet 4.6), and writes the resulting recommendations JSON back to Amazon S3.
- An Amazon Simple Notification Service (Amazon SNS) topic sends an email summary of the top recommendations to subscribers.
Figure 1 – Architecture diagram
Prerequisites
Before deploying the solution, make sure the following are in place.
- An Amazon Redshift Serverless workgroup with a database and query history.
- An Amazon Redshift database administrator user (superuser). The collector reads views that only a superuser can query (
SVV_TABLE_INFO,SVV_ALTER_TABLE_RECOMMENDATIONS,SVV_MV_INFO,SYS_SERVERLESS_USAGE,SYS_AUTO_TABLE_OPTIMIZATION).
Store the admin credentials in AWS Secrets Manager and pass the secret ARN to the collector.
Alternatively, have an existing superuser runALTER USER "IAMR:redshift-performance-recommendations-role" CREATEUSER;
once to grant the Lambda role superuser privileges. - Amazon Bedrock model access for the model of choice. For this solution, a
us.anthropic.claude-*model is recommended for multi-region inference. The solution doesn’t depend on a single model. - The AWS Command Line Interface (AWS CLI) installed and configured, and a clone of the GitHub repository.
Create the supporting resources
You need an Amazon S3 bucket, an Amazon SNS topic, an AWS Secrets Manager secret, and an AWS Identity and Access Management (IAM) role before the Lambda functions can run.
Create the Amazon S3 bucket
The Amazon S3 bucket will host the output report.
- Open the Amazon S3 console and choose Create bucket.
- Enter a globally unique name (for example,
amzn-s3-demo-bucket), keep the default settings, and choose Create bucket.
The collector writes telemetry JSON under the telemetry/ prefix and the analyzer writes recommendations under the recommendations/ prefix.
Create the Amazon SNS topic and subscription
Use Amazon SNS to generate notifications once reports are created.
- Open the Amazon SNS console and choose Topics, Create topic.
- Select Standard, and enter the name
redshift-performance-recommendations. - Choose Create topic.
- On the topic detail page, choose Create subscription.
- Select Email as the protocol, enter your email address, and choose Create subscription.
- Open the confirmation email from AWS Notifications and choose Confirm subscription.
Figure 2 – Create SNS Topic
Store the admin credentials in AWS Secrets Manager
To avoid using hard-coded credentials, create an AWS Secrets Manager secret to connect to Amazon Redshift.
- Open the AWS Secrets Manager console and choose Store a new secret.
- Select Other type of secret, choose the Plaintext tab, and paste the following, replacing
<ADMIN_PASSWORD>with the workgroup’s admin password: - Choose Next, enter
redshift-performance-adminas the secret name, then choose Next, Next, and Store. - Copy the secret Amazon Resource Name (ARN) from the secret detail page. You pass it to the collector in a later step.
Figure 3 – Create secret
Create the IAM role and attach the policy
The repository includes a trust policy in iam/trust-policy.json (allowing lambda.amazonaws.com to assume the role) and the least-privilege permission policy in iam/lambda-role-policy.json. Replace the <ACCOUNT_ID>, <REGION>, <YOUR_BUCKET>, and SNS topic ARN placeholders in the permission policy with your values, then create the role in the AWS Management Console or with this AWS CLI command:
The permission policy grants the Amazon Redshift Data API, Amazon S3, Amazon SNS, Amazon Bedrock, AWS Lambda invoke, AWS Secrets Manager, and Amazon CloudWatch Logs permissions that both Lambda functions require.
Deploy the Lambda functions
The collector source is in lambda/collector.py and it loads the SQL files in sql/ at runtime. The deployment package must contain both.
Package the collector
Open a terminal or shell window and execute a command to copy the collector code, supporting SQL into a folder and archive.
Create the collector function
Using the AWS Management Console, navigate to AWS Lambda.
- Choose Create function.
Figure 4 – Create AWS Lambda function
- Select Author from scratch, enter
redshift-performance-collectoras the name, and select Python 3.14. - Expand Custom settings, toggle Custom execution role, choose an existing role, select
redshift-performance-recommendations-role, and choose Save. - On the function page, choose Upload from, .zip file, and upload
build/collector.zip. - In Runtime settings, select Edit, and set the Handler to
collector.lambda_handler.
Figure 5 – Set AWS Lambda handler
- Choose Configuration, Edit, set timeout to 5 minutes, and memory to 256 MB.
Figure 6 – Set AWS Lambda timeout and memory
- Under Configuration, select Environment variables, and add the following keys:
WORKGROUP: your Amazon Redshift Serverless workgroup name.NAMESPACE_NAME: the namespace the workgroup belongs to.DATABASE:dev(or your target database).BUCKET: the Amazon S3 bucket name you created earlier.SECRET_ARN: the AWS Secrets Manager secret ARN you copied earlier.ANALYZER_FN:redshift-performance-analyzer.
Package and create the analyzer
Repeat the same steps for the analyzer, using lambda/analyzer.py with a 15-minute timeout:
Use the Lambda console to create redshift-performance-analyzer with handler analyzer.lambda_handler, timeout 15 minutes, memory 256 MB, the same execution role, and these environment variables:
BUCKET: the same Amazon S3 bucket.SNS_TOPIC: the SNS topic ARN.MODEL_ID:us.anthropic.claude-sonnet-4-6.
The analyzer creates the Amazon Bedrock client with read_timeout=600 and max_tokens=16384 to handle large prompts and long responses. Anthropic Claude inference on a full telemetry payload typically takes 2–4 minutes.
How the signals and the prompt work
You don’t write any custom code for signal computation or prompt construction. Both computation and construction live in the repository.
The compute_signals() function in lambda/collector.py scans the telemetry for Boolean and threshold-based anti-patterns. At the table level, it looks for row skew, ghost rows, stale statistics, unsorted data, sub-optimal sort or distribution keys, and oversized VARCHAR columns. It also flags runtime and workload issues such as disk spill, small-insert bursts, high Data Definition Language (DDL) executions, and unoptimized COPY file size. Beyond that, it catches Amazon Redshift Spectrum queries that fail to prune partitions and data sharing materialized views doing full refresh. It also flags WLM configurations that lack Query Monitoring Rules (QMR), such as limits on blocks spilled to disk and query execution time. The full set of signals and thresholds is defined inline in the function. To tune a threshold or add a custom signal, edit this function and redeploy.
The build_prompt() function in lambda/analyzer.py constructs the Amazon Bedrock prompt in four sections. The first section lists the triggered signals. The second adds CloudWatch metrics, annotated with >> CORRELATION lines that pair each signal with its supporting metric. The third includes the filtered supporting data, limited to the table and query rows that triggered a signal. The fourth gives explicit instructions to return a pipe delimited text where every recommendation references specific table names, query IDs, and metric values. This structure is why the model produces targeted output rather than generic best-practice advice.
Schedule daily runs
Use the Amazon EventBridge console to trigger the collector every 24 hours.
- Open the EventBridge console and choose Schedules under Scheduler, Create schedule.
- Enter the name
redshift-performance-dailyfor Schedule name, toggle Recurring schedule and Rate-based schedule. - Under Rate expression, enter 24 and select hours.
- For Flexible time window, choose Off, and select Next.
Figure 7 – Create Amazon EventBridge schedule
- On the Select target page, choose AWS Lambda, select the
redshift-performance-collectorfunction, and choose Next.
Figure 8 – Select Amazon EventBridge schedule target
- Accept the defaults for Settings and select Next. EventBridge automatically adds a resource-based permission on the Lambda function so the rule can invoke it.
- Choose Create schedule.
Run it once and review the output
Invoke the collector manually to confirm the pipeline works end-to-end.
- In the Lambda console, open the
redshift-performance-collectorfunction and choose Test. Create a test event namedmanualwith the body{}and choose Test.
Figure 9 – Test end-to-end workflow
- The function completes in under a minute. Check the Monitor tab for the invocation log via the CloudWatch live logs link.
- In the Amazon S3 console, open your bucket. Confirm that the
telemetry/prefix contains a JSON file with the current timestamp. - Within 2–4 minutes, the analyzer publishes a message to the SNS topic. Check the email address you subscribed for the summary with the top 10 recommendations. Confirm that the
recommendations/prefix in Amazon S3 contains the full JSON.
Each recommendation has a priority (critical, high, medium, low) and a category (query_optimization, table_design, capacity, wlm, maintenance, or ingestion). It also includes a signal_source that names the signals and CloudWatch metrics that triggered it, a plain-language explanation, a specific SQL or configuration action, and an expected impact estimate.
Figure 10 – Sample analyzer emailed output
Best practices
- Tune thresholds to your workload. The default thresholds in
compute_signals()come from the Amazon Redshift operational review playbook. For high-velocity ingestion or small-cluster environments, consider lowering the small-insert threshold, widening the stale-statistics window, or adding custom signals for your own tables. - Keep the signal-to-metric correlations current. When you add a signal, also add a matching correlation in
build_correlations(). The inline>> CORRELATIONlines are what make the model connect an infrastructure metric to an application-level symptom. - Review recommendations before you act. The analyzer produces prioritized suggestions, but
VACUUM,ANALYZE, andALTER TABLEactions change table state. Read the explanation and action on each recommendation, validate the SQL against your schema, and run it during a maintenance window.
Cleaning up
To avoid ongoing charges, delete the resources you created for this solution:
- The two AWS Lambda functions:
redshift-performance-collectorandredshift-performance-analyzer. - The Amazon EventBridge rule:
redshift-performance-daily. - The Amazon SNS topic and its email subscription:
redshift-performance-recommendations. - The Amazon S3 bucket, including the
telemetry/andrecommendations/objects. - The AWS Secrets Manager secret:
redshift-performance-admin. - The IAM role and its inline policy:
redshift-performance-recommendations-role.
Conclusion
You now have a daily performance review for Amazon Redshift Serverless that runs entirely on AWS Lambda, stores every run in Amazon S3, and delivers prioritized recommendations by email. The signal-based prompt pattern keeps the Amazon Bedrock cost low and the recommendations specific to your workload.
To learn more, see the following resources:
- Source code: sample-ai-performance-advisor-for-amazon-redshift on the GitHub website.
- Amazon Redshift system tables and views.
- Amazon Bedrock User Guide.
- Monitoring Amazon Redshift Serverless with Amazon CloudWatch.
About the authors
This is a Thing KYY X90G “Quad” Portable Monitor Review
Post Syndicated from Sam Sabinash original https://www.servethehome.com/this-is-a-thing-kyy-x90g-quad-portable-monitor-review/
Apparenty taking three 15.6″ IPS monitors with you to surround your laptop is a big productivity boost as we found in our KYY X90G review
The post This is a Thing KYY X90G “Quad” Portable Monitor Review appeared first on ServeTheHome.
Comic for 2026.07.01 – Seek Therapy
Post Syndicated from Explosm.net original https://explosm.net/comics/seek-therapy
New Cyanide and Happiness Comic
Upgrade Amazon EKS clusters with confidence using Kubernetes version rollbacks
Post Syndicated from Micah Walter original https://aws.amazon.com/blogs/aws/upgrade-amazon-eks-clusters-with-confidence-using-kubernetes-version-rollbacks/
Upgrading a Kubernetes control plane has long been a one way door. Open source Kubernetes doesn’t support control plane rollback, so once you upgrade, there’s no going back. The community is making real progress here, and KEP-4330 introduces emulated versions to ease rollback. But in practice this constraint has pushed organizations to build elaborate compensating mechanisms like bake periods, stagger groups, automated sign offs, and months long upgrade cycles. With Kubernetes releasing three minor versions per year, teams managing hundreds of clusters, especially in regulated environments, often delay upgrades entirely because they aren’t confident they can recover if something goes wrong. The result is clusters stuck on older versions, missing security patches, and eventually running up against extended support timelines.
Today, we’re announcing Kubernetes version rollbacks for Amazon Elastic Kubernetes Service (Amazon EKS), a new feature that gives cluster administrators a safety net when performing cluster upgrades. With version rollbacks, you can reverse a Kubernetes version upgrade within seven days if you encounter issues after upgrading, returning your cluster to its previous working state.
Where approaches like emulated versions keep a cluster in a transitional holding state, EKS version rollback returns your cluster to a fully validated previous version that ran in production, not an emulation of it. Now, if you upgrade a cluster from, say, Kubernetes 1.34 to 1.35 and discover a compatibility issue, you can roll back to 1.34 within seven days. There’s no need to rebuild your cluster or scramble to troubleshoot under pressure. Think of it as an undo button for Kubernetes version upgrades.
The feature supports rolling back one minor version at a time, matching the same incremental approach EKS uses for upgrades. And to help you roll back safely, EKS automatically evaluates your cluster’s rollback readiness through cluster insights, flagging items like node version compatibility or add-on dependencies before you proceed. If you’ve already assessed the situation and want to move quickly, you can use the --force flag to bypass those checks. The above applies to all EKS clusters, whether you manage your own nodes or let AWS handle them. But for customers who have embraced fully managed infrastructure, rollback goes a step further.
Rollback for EKS Auto Mode
EKS Auto Mode gives you one click deployment of production ready Kubernetes clusters, automating compute, networking, and storage management so you can focus on your applications rather than infrastructure. EKS Auto Mode introduces additional considerations for version rollbacks because both the control plane and managed nodes need to be rolled back together. Since node rollbacks respect your pod disruption budgets, the process can take time depending on your configuration.
To give you control over this process, we’ve introduced a cancel API that lets you stop a node rollback at any point. If you decide the rollback is taking too long or you want to change your approach, you can cancel and adjust your disruption budgets to accelerate things, or choose a different path forward.
By default, EKS never bypasses your disruption budgets during a rollback because we prioritize workload stability. You can always choose to modify or remove disruption budgets yourself to speed up the process if needed.
Let’s try it out
To try version rollbacks, I navigated to the Amazon EKS console and selected one of my clusters that I had recently upgraded.

From the cluster’s configuration page, I can see the option to initiate a version rollback, along with information about my current rollback window.

Before initiating the rollback, I reviewed the rollback insights to check for any potential issues. The insights showed me the status of my nodes and flagged anything I should address before proceeding.

After confirming, the rollback began. My cluster remained functional throughout the process. The control plane rollback took about 20 minutes, similar to a standard upgrade. For my EKS Auto Mode cluster, the nodes rolled back gracefully according to my disruption budget settings.

Once complete, my cluster was back on the previous Kubernetes version, running as expected.
Now available
Kubernetes version rollbacks for Amazon EKS are available today at no additional cost in all commercial AWS Regions where Amazon EKS is available. You pay only for the standard EKS and compute costs you would normally incur. There are no extra charges for using the rollback capability.
Control plane rollbacks are available for all EKS clusters, and node rollbacks are available for clusters running EKS Auto Mode. Version rollbacks support clusters running Kubernetes versions available in EKS standard support and extended support.
To get started, visit the Amazon EKS documentation or try it out directly in the Amazon EKS console.
[$] Efficient access to local storage for BPF programs
Post Syndicated from daroc original https://lwn.net/Articles/1078968/
When a BPF program is used to filter or redirect packets in the networking
subsystem, the program will often want to associate data with each packet as it
moves through the kernel. The kernel’s
local BPF storage API, which
associates extra data with some kernel objects, provides a way to do that. (See also
the BPF map types that end
in STORAGE.)
Amery Hung and Jakub Sitnicki led two sessions
at the 2026
Linux Storage, Filesystem, Memory-Management, and BPF Summit
about how to make accesses to local storage data more efficient. Hung spoke
about general performance problems related to locking, while Sitnicki examined
the use of local storage in the networking subsystem in particular.
Cinematic Portraits Using Colored LEDs
Post Syndicated from Matt Granger original https://www.youtube.com/watch?v=P9MZ--Hg2c0
What We Learned Filming "The American Revolution"
Post Syndicated from The Atlantic original https://www.youtube.com/shorts/q2ImR7UH4S8
Scranton’s Train Set: Last Week Tonight with John Oliver (Bonus Segments)
Post Syndicated from LastWeekTonight original https://www.youtube.com/watch?v=S0OiT5GOXaY
Soap Operas Update
Post Syndicated from LastWeekTonight original https://www.youtube.com/shorts/3wq8fb-ud-Q
How to use the AWS Workload Credentials Provider for cross-account secret retrieval and prefetching secrets
Post Syndicated from Derik Wang original https://aws.amazon.com/blogs/security/how-to-use-the-aws-workload-credentials-provider-for-cross-account-secret-retrieval-and-prefetching-secrets/
If you manage secrets across multiple AWS accounts or need faster secret access for latency-sensitive applications, this post shows you how to meet those requirements using two new features of the AWS Workload Credentials Provider (provider). You will learn how to configure role chaining for cross-account secret retrieval and prefetching of secrets to reduce cold-start latency.
By using role chaining, you can access secrets across AWS accounts through a single provider instance by assuming AWS Identity and Access Management (IAM) roles. Prefetching populates the provider’s in-memory cache with secrets at startup so your application can retrieve secrets without waiting for the first request to trigger a network call at runtime.
What is the AWS Workload Credentials Provider?
AWS Secrets Manager stores and rotates credentials, API keys, and other secrets. The AWS Workload Credentials Provider is a client-side HTTP service that retrieves and caches secrets locally. This reduces latency, improves availability during transient failures, and lowers costs. It supports post-quantum TLS by default, requires no language-specific SDK, and works across Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), and AWS Lambda. For more details, see the Workload Credentials Provider documentation and GitHub repository.
Security considerations
The Server-Side Requst Forger (SSRF) token prevents unauthorized processes from accessing the provider’s HTTP endpoint. Only applications that can read the token file can retrieve secrets through the provider.
Any identity that can access the provider’s endpoint and SSRF token can retrieve secrets through role chaining. This means users with compute environment access can retrieve cross-account secrets when role assumption is configured. Scope the target role’s permissions to only the secrets required by following the principle of least privilege.
For prefetching, secrets are loaded into the provider’s in-memory cache at startup. Any process that can reach the provider’s localhost endpoint and provide a valid SSRF token can retrieve prefetched secrets from the cache.
Cross-account secret retrieval with role chaining
Organizations might store secrets in a dedicated AWS account, or need to share one secret across applications in different accounts. Until now, cross-account retrieval through the provider required attaching resource-based policies directly to each secret. Some customers prefer IAM role assumption. Before this feature, you had to deploy multiple provider instances with different credentials or build custom credential-switching logic. The provider now supports both approaches: resource-based policies and IAM role assumption. While role assumption is especially useful for cross-account scenarios, it also helps within the same account when secrets are protected by different customer-managed KMS keys.
When you include the roleArn query parameter in a request, the provider uses AWS Security Token Service (AWS STS) AssumeRole to obtain temporary credentials for the specified role and retrieves the secret with those credentials. The provider creates and caches a separate client for each role ARN, so subsequent requests to the same role reuse the existing client. Each role client maintains its own independent cache.
Note: The source account runs the Workload Credentials Provider and your application. The target account contains the secret you want to retrieve. A single provider instance in the source account can assume roles in one or more target accounts.
Prerequisites
- A Workload Credentials Provider built and installed in your environment (see the README for build instructions)
- AWS credentials configured in your compute environment with permission to call
sts:AssumeRoleon the target role ARN- If you also retrieve secrets from the source account through the provider, the credentials need
secretsmanager:GetSecretValueandsecretsmanager:DescribeSecretpermissions for those secrets
- If you also retrieve secrets from the source account through the provider, the credentials need
- A secret in a target AWS account that you want to retrieve
- An IAM role in the target account with a trust policy that allows the provider’s identity to assume it
To build the Workload Credentials Provider
The provider is written in Rust and compiles to a single executable. The following steps are for an RPM-based system such as Amazon Linux 2023:
- Install build dependencies:
- Install Rust:
- Clone the repository and build the provider (use the latest tag available):
The compiled binary is at target/release/aws-workload-credentials-provider.
To install the Workload Credentials Provider on Amazon EC2
After building the provider, install it as a system service on your EC2 instance and configure access to the SSRF token.
- After configuring your
config.tomlfile (see Configuration options section), run the install script to deploy the provider as a systemd service and generate the SSRF token: - Add your application user to the
aws-wcp-tokengroup. This grants your application permission to read the SSRF token file, which is required for all secret retrieval requests:
To install on Amazon ECS, Amazon EKS, or Lambda, see the installation instructions in the GitHub repository.
To verify the installation
- Check that the provider is running:
- You’ll receive a JSON response with the secret value. If you see a connection refused error, check that the provider process is running. If you see a 401 or 403 error, verify the SSRF token file is readable and that the provider’s IAM credentials have
secretsmanager:GetSecretValueandsecretsmanager:DescribeSecretpermissions.
Required permissions
The provider’s base IAM identity requires:
sts:AssumeRoleon the target role ARN
The target role requires:
secretsmanager:GetSecretValuesecretsmanager:DescribeSecret
To configure the target account IAM role
Create an IAM role in the target account with a trust policy that allows the provider’s identity in the source account to assume it. Then attach a policy that grants access to the required secrets.
- Create an IAM role in the target account with a trust policy that allows the provider’s identity in the source account to assume it.
- Attach a policy to this role that grants access to the secret:
To configure the source account IAM role
Before the provider can assume the role you created in the target account, grant it permission to call sts:AssumeRole. Attach the following policy to the provider’s IAM role in the source account:
To retrieve the cross-account secret
Call the Workload Credentials Provider endpoint with the roleArn parameter. The following curl example shows how to retrieve a secret using a different IAM role:
The following Python example shows the same operation:
You can configure the maximum number of simultaneous assumed roles with the max_roles option in the provider’s TOML configuration file. The default is 20, and the range is 1–20.
Prefetching secrets at startup
By default, the Workload Credentials Provider populates its cache lazily—the first request for a secret triggers a network call to Secrets Manager. Prefetching reduces this cold-start latency by loading secrets at startup.
How prefetching works
You can configure prefetching by adding a [capabilities.secrets_manager.prefetch] section to the provider’s TOML configuration file. You can specify secrets to prefetch in two ways:
- Explicit secrets – List specific secret IDs or ARNs using
[[capabilities.secrets_manager.prefetch.secrets]]entries. - Tag-based discovery – Discover secrets by tag key using
[[capabilities.secrets_manager.prefetch.filter_tags]]entries. The provider callsBatchGetSecretValuewith tag key filters to find and cache all matching secrets.
You can use both methods together. Each entry optionally accepts a role_arn field for cross-account prefetching through role chaining.
Required permissions
The following permissions are required on the IAM role that performs the prefetch, depending on whether the secrets are in the source account or a target account.
secretsmanager:BatchGetSecretValue– Required on the source account role for source-account secrets, or on the target role for cross-account secretssecretsmanager:ListSecrets– Required when using tag-based discovery (filter_tags), on whichever role is performing the discovery
Configuration options
You can tune prefetch behavior with the following options in the [capabilities.secrets_manager.prefetch] section of your TOML configuration file:
- cache_buffer_ratio – The maximum fraction of the cache to fill per caching client during prefetch, in the range 0.1–1.0. The default is 0.8. For example, if your cache holds 100 secrets, a ratio of 0.8 prefetches up to 80, leaving room for 20 on-demand secrets to be cached.
- max_jitter_seconds – The maximum random delay in seconds before starting the prefetch task, in the range 0–10. The default is 0 (no jitter). Use this to prevent fleet-wide synchronized API calls when deploying across many instances.
Example: Prefetch with explicit secrets
The following configuration prefetches two secrets at startup, one from the source account and one from a different account using role chaining:
Example: Prefetch with tag-based discovery
The following configuration discovers and caches all secrets tagged with the Environment key, and all secrets tagged with the Team key in a different account:
Example: Full configuration
The following example shows a complete provider configuration that combines both features:
Start the provider with your configuration file:
Conclusion
This post showed you how to use role chaining for cross-account secret retrieval and prefetching to reduce cold-start latency. Role chaining simplifies multi-account architectures—a single provider instance can retrieve secrets across accounts using IAM role assumption. Prefetching reduces cold-start latency by populating the provider’s cache before your application makes its first request. Combined, these features let you run the Workload Credentials Provider across multiple accounts with faster secret access.
Further reading
- AWS Workload Credentials Provider documentation
- Access AWS Secrets Manager secrets from a different account
- GitHub repository for source code and README
- AWS Secrets Manager documentation
Submit feedback in the comments below, or contact AWS Support with questions.
5 Myths About AI in the SOC Security Teams Need to Rethink
Post Syndicated from Emma Burdett original https://www.rapid7.com/blog/post/ai-rethinking-5-soc-myths
AI is now part of almost every conversation in security operations. Most teams are already investing in it, experimenting with it, or trying to understand where it fits. The challenge is not whether to adopt AI, but how to apply it in a way that actually improves outcomes.
At the Rapid7 Global Cybersecurity Summit, the session The AI Dilemma: Automating Defense Without Surrendering Judgment explores how AI is being used in the SOC today, and where it creates real value in practice.
The discussion centers on a set of assumptions that often shape how teams approach AI, and why those assumptions do not always hold up in real environments.
Myth 1: AI will replace analysts
Across the session, there is a consistent focus on how AI supports investigation workflows by reducing repetitive work and surfacing relevant context, allowing analysts to focus on decisions that require judgment. AI helps teams move faster, but responsibility and accountability still sit with people. TL;DR, the role of the analyst is evolving, but it is not disappearing.
Myth 2: More automation means better security outcomes
Automation is valuable when it is applied in the right places. In practice, teams are finding the most benefit in areas such as enrichment, summarization, and triage, where large volumes of data need to be processed quickly. High-impact actions such as containment or configuration changes still require oversight, particularly when they can affect production systems or business operations.
Myth 3: Speed is more important than transparency
As adoption increases, trust becomes more important and analysts need to understand how a conclusion was reached before they act on it, especially in high-pressure situations. The session highlights how explainability builds confidence over time, allowing teams to rely on AI outputs without losing control of the decision-making process.
Myth 4: AI is only about efficiency gains
Efficiency is part of the story, but the impact runs deeper. AI helps connect signals across fragmented environments, reduces cognitive load, and supports more consistent decision-making. It also changes how teams approach investigation by making it easier to surface patterns and identify relationships that would be difficult to see manually.
Myth 5: Attackers benefit more from AI than defenders
Both attackers and defenders are learning how to use AI, and both are moving quickly. What matters for security teams is how they apply it within their own workflows. The session explores how AI strengthens detection, investigation, and response when it is integrated into existing processes rather than treated as a standalone capability.
Where AI creates real value in the SOC
Across the discussion, a clear pattern emerges. AI delivers the most value when it is applied to high-volume, context-heavy tasks, where it can process data, highlight signals, and recommend next steps. Analysts remain central to interpreting those signals, understanding intent, and deciding how to respond.
This balance between automation and oversight is what allows teams to scale their operations without losing confidence in their decisions. It also reflects how AI is being adopted across the industry, with most organizations maintaining moderate to high levels of human involvement as they build trust in these systems.
For SOC leaders, practitioners, and teams exploring AI, the session offers a grounded view of how these technologies are being applied today, and how that approach is continuing to evolve.
Watch the full session to explore how transparent AI supports better decisions in the SOC and how teams are applying it in practice.
America at 250: Is the Experiment Failing? | The David Frum Show
Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=3fXErHBi-Dw
Home Assistant 2026.7 Finally Fixes This
Post Syndicated from BeardedTinker original https://www.youtube.com/watch?v=m4SDwP_l5cc
[$] Secure Boot certificate expiration is here
Post Syndicated from jzb original https://lwn.net/Articles/1079808/
Linux users who have Secure Boot enabled on
their systems rely on certificates issued by Microsoft to verify the software
used to boot a system is trusted by the user. One of those certificates expired
recently, but that will not cause systems that are able to boot to stop doing
so. There are situations where the expiration may cause problems, however, and
the window for relying on existing signed binaries is shorter than it might
appear. Users and administrators will want to stay on top of these changes. Over
the last year, part of my job at Microsoft has been to work on this
problem. LWN wrote about the
certificate expiration in July 2025, and this article follows up with where
we are now.
Security updates for Wednesday
Post Syndicated from jzb original https://lwn.net/Articles/1080689/
Security updates have been issued by AlmaLinux (coreutils, galera and mariadb11.8, giflib, git-lfs, glibc, httpd, kernel, mariadb10.11, mod_md, perl-Archive-Tar, perl-IO-Compress, perl:5.32, rrdtool, ruby, ruby4.0, and thunderbird), Debian (debian-security-support, librabbitmq, and nginx), Fedora (chromium, collectd, maradns, python-django-haystack, python-jupytext, varnish, varnish-modules, and vmod-querystring), Oracle (firefox, git-lfs, kernel, nginx:1.24, openssl, perl-Archive-Tar, perl-IO-Compress, and uek-kernel), Red Hat (container-tools:rhel8), SUSE (7zip, apache2, buildah, cifs-utils, curl, docker, exiv2-0_26, libonnxruntime1, libsoup, nodejs22, opensc, pacemaker, perl-Config-IniFiles, podman, sg3_utils, socat, tar, tracker, and xdg-desktop-portal), and Ubuntu (curl, hplip, libgd-perl, libssh2, libyang, ruby2.7, ruby3.0, ruby3.2, ruby3.3, and tar).
НВО: Време изпитно
Post Syndicated from original https://www.toest.bg/nvo-vreme-izpitno/

Този разказ се основава на лични преживявания. За съжаление, на такива, които не са изключение, а се повтарят ежегодно за родителите на седмокласници в съответната година.
Brace yourself и отивай на НВО
Рано или късно семействата с деца стигат до съдбоносната учебна година на седми клас и изпитите, с които тя завършва – националното външно оценяване по български език и литература и по математика. От самото си начало тези два изпита станаха „изпити с голям залог“ (high-stakes testing).
High-stakes testing са стандартизирани тестове, чиито резултати директно определят бъдещия път на изпитвания в дадена сфера. Примери за такива тестове са: дипломни и държавни изпити, изпити, които дават правото да се практикува дадена професия или да се получава стипендия, и т.н.
Отличителните им белези са:
- единно дефинирано оценяване;
- преки последици за успешното или неуспешното изпитание (нещо е заложено на карта);
- ясна граница между тези, които са издържали, и тези, които не са.
Въпреки че при НВО в седми клас нямаме рязка граница между „издържал“ и „неиздържал“, със сигурност знаем от опит, че резултатите от изпитите са решаващи дори в рамките на половин точка.
Терминът high-stakes testing произлиза директно от хазартната концепция. Там при игра с високи залози се излага на риск голяма сума според личната преценка на играча. В случая с изпитите прилагането на подобна система е свързано с несигурност и потенциални загуби за участниците в теста, които трябва да го „спечелят“, вместо да могат да постигнат целта си по друг начин.
РУлетка или рОлетка?
Рулетката е хазартна игра, в която трябва да се предвиди къде ще падне въртящото се топче. Играчите правят залози и играят срещу казиното, представено на игралната маса от крупието.
Ролетката е уред за измерване на дължина с точност до милиметър.
Кое мери учениците в седми клас – рулетката или ролетката?
Министерство на образованието и науката (МОН) смята, че ги мери с „ролетка“. Всяка задача е точкувана и измерва знанието в брой точки. Ежегодно МОН публикува модели на предстоящите изпити, като на първо място изброява целите им:
- диагностика на индивидуалния напредък и на образователните потребности на учениците от седми клас;
- мониторинг на образователния процес за прилагане на политики и мерки, насочени към подобряване на качеството на образованието;
- установяване на степента на постигане на отделни очаквани резултати от обучението по български език и литература, определени в учебната програма за съответния клас;
- установяване на степента на постигане на отделни очаквани резултати от обучението в края на прогимназиалния етап по български език и литература/математика, определени в Държавния образователен стандарт за общообразователна подготовка;
- използване на резултатите от НВО по български език и литература/математика като балообразуващ елемент при приемането на ученици в осми клас.
Всяка година учители, експерти, родители и ученици се питаме как един и същи инструмент е способен да измери всичко изброено. Питаме се също така къде остават мерките, които са необходими за повишаване на качеството на образованието. Питаме се и за последствията от недостатъчната степен на очакваните резултати. Защото никоя от тези цели не бива разглеждана след изпитите така, както последната – използване на резултатите като балообразуващ елемент при приема в осми клас. Ето така, като се забравя удобно за какво са въведени изпитите, те се превръщат в изпити с голям залог. Не била ролетка, най ми била рулетка.
Знаете ли, че…
… всяка година около датите на изпитите тръгват разкази как изпитните варианти са изтекли. Всички знаят, всички мълчат. Дори и в МОН.
Настоящата рубрика е повод често да бъда търсена по образователни казуси в качеството си на журналистка. Не просто защото имам трибуна, от която даден казус може да стигне до по-голяма публика, но и основно защото Етичният кодекс на българските медии защитава анонимността на информаторите и поверителните източници чрез строги професионални правила. Ето така тази година в деня на изпита по български език и литература, малко след изтичането му, получих снимки на целия изпит от читател. На тях освен теста ясно се виждат краката на квесторката, както и списъци на учениците от стаята, в която е заснет. Дори името на училището е видно.







Информаторът ми, без да е заявявал интерес да получи подобни снимки, се сдобива с тях в края на изпита. Но те отдавна са послужили там, закъдето са били поръчани. След споделянето на този факт в тесен кръг се оказа, че това е публичната тайна за една ежегодна практика: всяка година изпитът изтича още сутринта и обикаля определени кръгове.
Рязко си спомних края на 90-те, когато вечерта преди изпита по география в един от родните университети моя съученичка чува темата от съседна маса в заведение и решава да си я припомни още веднъж за всеки случай. На следващия ден беше щастлива, че е вечеряла с родителите си точно в този ресторант…
Знаете ли, че…
… конспектът по литература за седми клас включва 11 автори и общо 22 творби? С най-много произведения в него присъства Иван Вазов – общо 6. Никой от останалите автори не е включен с повече от две произведения.
… тезата е задача с разширен свободен отговор, която винаги е формулирана така: „Запишете в текст от 3–4 изречения какво е внушението на думите [следва цитат от произведение]“. За последните 18 години (от 2009 до 2026 г.) цитат от произведение на Иван Вазов е бил тема за тезата цели 12 пъти. Йордан Йовков – 2 пъти, Пейо Яворов, Алеко Константинов, Христо Ботев и Елин Пелин – по 1 път. Останалите автори – Любен Каравелов, Веселин Ханчев, Христо Смирненски, Добри Чинтулов и Пенчо Славейков – все още не са удостоени с честта.
… правилният отговор на следния въпрос би ви донесъл 2 точки на НВО, но не е ясно какво точно знание ви носи:
Пейзажът изгражда атмосфера на приказна тайнственост в:
А) „Косачи“
Б) „Радини вълнения“
В) „Хубава си, моя горо“
Г) „Бай Ганьо пътува“
Дали познахте, че отговорът е А? Дори и да не сте, съм сигурна, че когато чуете „Косачи“ на Елин Пелин, в съзнанието ви изниква романтичният млад и наивен Лазо, който тръгва през нощта, за да се върне при булката си. Но спокойно, предстои XI клас, когато в учебната програма отново ще влезе същият разказ на същия автор.
Единственият досег на седмокласниците с нещо от времето, в което живеят, е преразказът на непознат текст. Остава загадка обаче по какъв критерий се определя произведението. За сметка на това почти всяка година (с малки изключения) някой от тези две страници текст размахва укорително показалец към децата и уж ги учи на кураж и/или честност, но с наратив, който по-скоро ги отблъсква, отколкото да ги заговаря. Ето само три изречения от тазгодишния разказ:
Когато дойде лятото, той – вместо да се радва на ваканцията – започна да учи. По цял ден стоеше в стаята си и четеше. Излизаше само до библиотеката.
Да, напълно реален сценарий за всеки 14-годишен, но друг път.
По математика тази година турбуленциите бяха огромни
След предложения за нововъведения, които все пак не бяха осъществени, и след пълния мрак, в който учителите трябваше да готвят седмокласниците, защото нямаше яснота как ще изглеждат цели 7 задачи от изпита, в крайна сметка (както се и очакваше заради новия тип задачи) резултатите са по-ниски, отколкото миналата година.
Задача 21 с един злополучен равнобедрен триъгълник беше дълго дискутирана тема и въпреки възражението от Съюза на математиците, на граждани, на преподаватели и на експерти МОН реши, че математиката не е вече точна наука и позволява творческа интерпретация. Така бяха присъдени 2 точки за грешен отговор, 3 точки, ако е посочен грешният и правилният и 4 точки, ако е посочен само правилния отговор. Така децата, които наистина разбират задачата, получават само една точка повече от тези, които не я разбират. Дали ще има статистика колко такива подарени точки има? Не, разбира се. Това е образование, не е концерт по желание.
Какво точно измери и тази година НВО?
Може би си мислите, че то измерва как са образовани децата? Може би си мечтаете то да измери качеството на преподаване на отделни учители? Може би ви се иска то да помага за намирането на силните страни на всеки ученик? Или пък си представяте как то е измерило ползи или вреди от поредно пренареждане на учебната програма? За съжаление, нито едно от тези неща.
НВО-то измери:
- колко семейства имат финансовите ресурси за частни уроци и школи;
- кои семейства могат да се справят със собствени сили с безумното предизвикателство, защото родители, баби и дядовци имат необходимата академична подготовка, за да помогнат на децата;
- кои деца от кои точно семейства остават изцяло извън радара на образователната система.
- единиците, които са се справили със собствени усилия, също остават незабелязани.
Но тези реални измервания никога не са били обект на анализ. Министърът на образованието в част от коментара си относно резултатите от НВО казва също:
Неслучайно системата обрасна с толкова нерегламентирани плащания, частни уроци. Това не е обвинение към българските учители, напротив.
Интересно, имаме министър, който обърна внимание на това!? Дали ще започне най-после този разговор?
Announcing the Monetization Gateway: charge for any resource behind Cloudflare via x402
Post Syndicated from Rohin Lohe original https://blog.cloudflare.com/monetization-gateway/
Today, we are announcing the Cloudflare Monetization Gateway, an engine that will give Cloudflare customers the ability to charge for any asset protected by Cloudflare: web pages, datasets, APIs, or MCP tools.
It will provide a single control plane to manage payment policies and access controls across your applications, while also protecting your origin from high payment volumes by handling payment verification and enforcement at the edge. At launch, payments will settle in stablecoins over x402, the open protocol we are building with a coalition of more than 25 industry leaders via the x402 Foundation.
For 30 years, the web has run on a simple economic bargain: trading content for human attention. That attention has been monetized through advertising, subscriptions, and e-commerce. This bargain funded the Internet as we know it.
But as agents become the dominant Internet users, the model is breaking. An agent does not look at ads or need to maintain a monthly subscription to all the tools it wants to access. It reads a page or consumes a data feed once, takes what it needs, and moves on. Across the web, AI crawlers already request content anywhere from a hundred to tens of thousands of times for every visitor they send back.
This reality demands a new model: usage-based pricing for everything. If attention and e-commerce are moving from websites to AI harnesses and AI-written software, then agents should pay for the inputs they need — training data, inference content, developer tooling, and API usage. The natural unit of payment for software is the request, the token, or the outcome, not the seat or the month. A few examples of what that could look like:
-
A few cents per web search, billed per call
-
\$0.001 base fee plus a \$0.01 per MB charge for an upload endpoint
-
\$0.99 per resolved support escalation, paid only when the work succeeds
This is the same shift behind paying creators when an answer engine uses their content — a fair exchange of value whenever content or a resource is used, priced on neutral rails built for the purpose. People often envision an agent buying high-priced assets like web domains, but most of what an agent pays for sits upstream of any checkout, and is priced far lower.
Some of the Internet already works this way. Cloud and APIs have been sold by the call and by the hour for years, but only to a known buyer: a user signs up, they are issued an API key, and they incur usage-based metered billing. Content mostly skipped payment and ran on advertising instead. These business models have never been able to serve unverified buyers for sub-cent transactions because the payment rails cost too much and took too long to settle. Below a certain price, collecting the payment cost more than the payment was worth.
Historically, usage-based billing was difficult to implement. Businesses needed to effectively become payments companies, running their own accounting to track internal usage in a robust and auditable way. Tracking this usage required significant overhauls of backend systems. Many instead chose per-seat pricing because it is simpler and frequently more profitable.
Agents flip this dynamic. A single agent can do the work of an entire team around the clock, making a flat one-time fee disconnected from actual consumption. At the same time, an agent can make thousands of micropayments without friction, while asking a person to approve each payment would be impossibly burdensome. Usage-based price points are where agents live and where stablecoin-based micropayments shine. That’s because stablecoins (such as Open USD and USDC) allow buyers to transfer tiny sums across the Internet, incurring negligible fees and settling in less than a second. This is not feasible with other payment rails today.
Here’s where we can help. Cloudflare has spent years building usage-based accounting for our own billing systems and for our customers’ analytics. We can dramatically simplify the implementation of usage-based billing for web-based assets thanks to our position as a proxy layer between buyers and sellers. As shown below, with Cloudflare supporting usage-based billing, the evidence of payment can move into the request itself, and the payment validation and the request paths merge.

And here’s the benefit to you: the metering, the payment exchange, and the settlement move off your origin. What stays with you is what matters — your rules, your prices, and your revenue. You will not need to onboard the buyer or stand up a billing system. You will write a rule and agentic buyers will pay for what they use.
Last year on Content Independence Day, we gave site owners one-click control over which AI crawlers could reach their content, and with Pay Per Crawl we let them charge crawlers for it. The Monetization Gateway is the next step: instead of only charging crawlers for content, you will be able to charge any caller for any resource, from an API to data to an MCP tool call, and you will not have to build the payment machinery yourself.
x402 is an open protocol that makes it possible to pay over HTTP, named for the 402 status code it finally puts to use. The x402 exchange is simple: a client requests a payment-gated resource. Instead of serving it, the server responds with 402 Payment Required and a small payload that states the price, the accepted asset, and where to pay. The client pays and repeats the request with proof of payment attached. A facilitator verifies, and the server returns the resource. It all happens inside ordinary HTTP requests and responses, with no redirect to a checkout page and no separate payment API to call. Settlement happens peer-to-peer, so any funds that a buyer sends to a seller are directly deposited to the seller’s wallet. We are designing the Monetization Gateway to keep payment overhead low and are aiming for sub-second payment settlement.

x402 Payment Flow: AI Agent ↔ APIServer ↔ Blockchain, Source: x402 Readme on GitHub
Two properties make x402 a good fit for machine payments. The payment amounts can be small, down to fractions of a cent, because the protocol adds almost no overhead. And the buyer needs no account with the seller, because the payment itself is the credential. x402 is rail agnostic, but it is a natural fit for stablecoins, which can settle in under a second for a fraction of a cent with zero chargebacks.
The Monetization Gateway will provide a flexible payment rules API that will allow you to express exactly when you want a caller to pay to access your digital resources.

Here’s how it will work. Tokens, APIs, MCP tool calls, and data already flow through that path. You will decide, as precisely as you want, which of that traffic has to pay. And you will be able to enforce your decisions by writing expressions, similar to expressions that you already write for other Cloudflare rules, in a simple, dedicated product API. The Monetization Gateway will scale with Cloudflare’s global network across 330+ cities, which means that the x402 handshake will occur in close proximity to your buyer. This will reduce request latency and protect your origin.
A few examples of planned capabilities:
-
Charge for specific REST verbs: Require payment on calls to a specific route, for example $0.01 for every GET or POST request to /api/premium/*.
-
Variable pricing: Charge variable amounts for tasks of varying complexity, for example, image generation might charge any amount up to $2, depending on the compute used.
-
Charge only unauthenticated callers: Intercept HTTP 401 “Unauthorized” responses from your origin and return 402 “Payment Required” instead with pricing and payment instructions.
When a request matches, the Monetization Gateway will verify payment before letting it through. You will be able to set these rules in the dashboard, or manage them as code through the Cloudflare API and Terraform, so a paid endpoint is just another part of your infrastructure config.
The Monetization Gateway will initially allow users to require buyers to pay for services and resources in stablecoins. Sellers will be able to use the stablecoins they accumulate for their own transactions or redeem the stablecoins for equivalent fiat currency in their bank account. Using the Monetization Gateway offers a way to increase the addressable market for your products. With the Gateway, agents can request your resource, be told the price, pay, and get the response. No signup, no API key, no prior relationship required. You will decide how much you need to know about that buyer, and you will have the flexibility to require agents to authenticate with Web Bot Auth and apply usage-based pricing against accounts they already hold.
The Monetization Gateway will turn the request into a payment and give Cloudflare customers new revenue opportunities, but where this goes is far bigger.
An agent is software that acts autonomously on a user’s behalf, and agents are starting to act on their own. Soon they will carry wallets and buy what they need without a person in the loop: a dataset, an API call, a tool, a block of compute. Some of those resources will be free, and some will require proof of who the agent is and who it acts for, through verified agent identity. Many will require both an identity and a payment, and Cloudflare is one of the few places that will be able to settle all of it inside a single request, by verifying the agent, applying the rule, and checking the payment before the origin ever sees the call. The agent becomes the primary buyer on the Internet, and the request becomes the transaction.
There is an enormous amount of value moving across the Internet today that goes unmonetized or undermonetized, not because no one would pay for it, but because the tools to charge for it have never existed. Every useful API call, every answer, every tool invocation an agent makes has value, and almost none of it is paid for today. That is the opportunity in front of us, and it is what the Monetization Gateway will unlock.
This is what we are building toward: an agent-first Internet with Internet-scale settlement built in. Where the people who make something worth paying for get paid by the software that uses it, automatically. And where the smallest new API can reach the same buyers, on the same terms, as the largest company on the web, and the independent creator is paid by the large language models that use their work. That is the next business model of the Internet, and we are building to power it.
The Monetization Gateway waitlist is open now for Cloudflare customers. If you’re interested in monetizing your web page, dataset, API, or MCP tool with usage-based pricing, please join our early access list.

Content Independence Day, one year on: building the business model for the agentic Internet
Post Syndicated from Arielle Weiss original https://blog.cloudflare.com/agentic-internet-bot-report/
One year ago, we declared Content Independence Day. At the time, we could see what many in the industry were beginning to sense: the fundamental economics of the Internet were shifting. AI adoption was accelerating, publishers were experiencing rapid declines in referral traffic, and AI companies were crawling the web at unprecedented scale, often without clearly declaring intent, and almost always without compensation.
We changed the defaults. For all new domains on Cloudflare, AI training crawlers would be blocked by default unless domain owners chose otherwise. We didn’t do this to wall off the web. We did it because we believed a healthier ecosystem required transparency, control, scarcity, and ultimately, a market where high-quality content could be valued and exchanged fairly.
A year later, that market has emerged. But the transformation of the Internet has happened even faster than we anticipated. In this report, we share key data points that illustrate how quickly the business model of the Internet has shifted – and what this new content market means for publishers and site owners.
AI is not just another technology cycle. It is a platform shift happening at more than 2x the speed that smartphones were adopted. In just 3.5 years, over 30% of humanity — 2.5 billion active users — has adopted regular use of generative AI. The adoption curve isn’t merely steep: it’s going vertical.

Never before have we seen such a rapid change in how humans interact with information, perform work, and spend time online.

The way people use the Internet is changing dramatically. Today, for every hour spent online searching for information, only 15 minutes is spent on the open web. Traditional search behavior is collapsing as users shift to AI-driven discovery and consumption. Instead of visiting multiple sites to source and compare information, users simply type a prompt and receive a nearly instantaneous, consolidated answer.
This year, agent traffic crossed a historic threshold for the first time: more than 50% of traffic on the Internet is now non-human. This shift has staggering implications for publishers, content owners, and the future of the open web.

When looking at the crawlers Cloudflare identifies by purpose, the composition of crawler traffic tells the story clearly:
-
52% of crawler requests are now for AI training as of June 2026, up from 22% in Spring 2025.
-
Mixed-use crawlers (those blending search, agent use, and training) represent over 36% of activity.
-
Pure search crawling now represents a small and declining share of overall crawler activity, despite remaining critical for publisher visibility.

As AI training becomes a primary driver of crawler activity, the ability to distinguish between discovery and training becomes increasingly important. Mixed-use crawlers blur that distinction, putting content owners in a difficult position: choose between remaining discoverable in the agentic era, and giving away their most valuable content without compensation.
For decades, the economic model of the open web was straightforward. Content creators exchanged access to their content for visibility in search engines, which returned referral traffic. That traffic became the primary mechanism through which publishers, creators, and businesses generated economic value.
But today, that exchange is breaking down. Content is still being crawled, indexed, and used — but increasingly without corresponding traffic being returned to the source. As AI systems answer questions, compare products, conduct research, and complete tasks directly, information across the open web is increasingly becoming part of AI training and retrieval systems. The existential question this raises is simple: if content is consumed without audiences ever visiting the source, how do content creators sustain themselves?

The earliest industries to feel the impact were news organizations and media companies. Today, similar dynamics are impacting businesses across retail, software, IT, and finance. Some of the most heavily crawled categories have seen human traffic decline as much as 40% in less than one year.

Many publishers are now preparing for what they call “Google Zero” — a world where little to no traffic comes from search referrals.
The implications extend to essentially every industry. Any organization that publishes proprietary information on the Internet will need to understand how to operate in an agentic era. This dynamic matters not just to content owners, but to all of us. The Internet is a critical part of the global economy and one of the world’s most important public resources for surfacing information. Ensuring it remains healthy and sustainable is essential for all.
When we launched Content Independence Day, we committed to three things:
-
Transparency and control for site owners, enabling them to define how their content is accessed and monetized.
-
Tools that create scarcity, shifting the balance of power back to content owners.
-
A marketplace where content creators and AI companies of all sizes can discover, license, and determine the value of content more efficiently.
One year later, a market for monetized content is here, and the conditions for a dynamic marketplace are forming.
Historically, publishers have had limited visibility into how AI companies accessed and used their content. As referral traffic declined, that lack of visibility became an economic problem prompting publishers to seek new ways to capture value.
Cloudflare’s attribution, business intelligence, and enforcement tools gave publishers visibility into AI consumption at the network level — an enforcement mechanism far more effective than voluntary standards like robots.txt. For the first time, publishers could determine how their content was accessed and monetized. That control created scarcity, and drove a supply-and-demand content economy.
Publishers that exercised control over access successfully created scarcity, giving them negotiating leverage that led to better deals. For the first time, publishers gained operator-level attribution data — evidence of how often LLMs attempted to access their content, which competitive LLMs were crawling, what their most in-demand URLs were, and what their crawl-to-referral ratios looked like. This reduced information asymmetry in licensing discussions and enabled publishers to negotiate from a position of knowledge.
This leverage has empowered our customers. As they have gained greater visibility into how AI systems access and use their content, they’ve become better equipped to understand the implications for their businesses and more confidently articulate the value of the information, brand, and audiences they have built.
As the balance of power between content owners and AI companies begins to change, a licensing economy is emerging:
-
More than 50 publisher-AI agreements have been signed since 2023.
-
Major AI companies now actively license content, increasingly recognizing the value of differentiated and premium content.
-
Collective licensing models continue to emerge and scale.
-
Large publishers are securing meaningful licensing agreements, demonstrating that content has real economic value within the AI ecosystem.
The conversation is no longer whether content should be compensated. The conversation now is how.
Early licensing agreements proved demand exists, but licensing today remains largely bespoke and unlikely to fully replace lost referral, advertising, and affiliate revenue. As a result, publishers are increasingly optimizing for AI consumption alongside traditional human discovery while exploring new monetization pathways.
Supply and demand remain difficult to match efficiently, and while there’s an understanding that not all content carries the same value, content valuation is still unresolved.
No discussion of this market is complete without addressing Google’s unique role. Google remains the dominant gateway to online discovery, accounting for approximately 88% of referral traffic. But increasingly, Google is helping users consume content directly within Google-owned AI experiences.

Discovery and consumption serve fundamentally different purposes. Search drives users to content, while AI-powered experiences increasingly summarize and reuse it without requiring users to visit the source. Website owners view these activities differently because one generates traffic, while the other increasingly substitutes for it.
These differences become especially important when site owners are deciding who should be allowed to access their content and for what purpose. Most leading AI companies separate discovery crawlers from training crawlers, making it relatively simple for publishers to enable content access for one purpose or the other. Google does not. Today, Google has access to about 2x more information than leading AI companies because Google leverages a mixed-use bot that makes it difficult for customers to participate in Google’s search ecosystem without also participating in Google’s AI ecosystem.
Unlike other AI providers, Google’s mixed-use crawler also limits transparency for site owners. Because discovery and AI access are combined into a single crawler, publishers cannot tell why Google is accessing their content or distinguish between traffic used for search and traffic used for AI experiences. They also lose the visibility and evidence that comes from being able to allow or block these activities independently at the network level.
This dynamic has accelerated demand for greater transparency and control, as well as new monetization models to better serve both content owners and AI companies of all sizes.
Cloudflare sits at the intersection of the emerging agentic economy.
More than 20% of the web sits behind Cloudflare’s network. Of the world’s most-visited websites, 36% rely on our network, and more than 40% of the Fortune 500 are Cloudflare customers. Nearly 80% of leading AI companies use Cloudflare, alongside thousands of developers and emerging AI companies.
This unique position gives us visibility into both sides of the market. We see the content owners creating content, the AI companies consuming it, and the signals increasingly connecting them. That perspective has given us a unique view into how the market has evolved over the past year, and what it now requires.
As publishers and AI companies adapt to a new agentic economy, Cloudflare has gained a clearer understanding of what the ecosystem now needs.
Content owners increasingly need visibility and control over who is accessing their content, how it is being used, and for what purpose. AI companies increasingly recognize that transparency builds trust and reduces friction with publishers. Visibility and enforcement are no longer security concerns alone — they have become business requirements that directly influence licensing negotiations and commercial decision making.
To help make transparency the standard, Cloudflare is continuing to invest in enhanced attribution, measurement, and publisher controls that give content owners greater visibility into and control over how their content is accessed and used.
As the industry shifts toward greater transparency, we believe that verifiable bot self-identification and declarations of crawl intent are fundamental to a sustainable ecosystem. Today, more than one-third of crawler activity on our network still comes from mixed-use bots that make it impossible for content owners to distinguish crawl intent. We are actively engaging with the ecosystem and investing in tooling to help drive that number to zero by this time next year.
Over the past year, it has become increasingly clear that AI companies need more than access to content. They need better ways to determine what to access, when to access it, and how frequently it has changed. Indiscriminate crawling wastes compute for AI companies and creates unnecessary bandwidth burden for publishers, reducing efficiency across the ecosystem.
We believe better answers require better intelligence. We are investing in real-time freshness signals with richer trust, quality, and relevance to help AI companies discover differentiated information while reducing unnecessary crawling across the web.
We believe better discovery must precede better pricing. In order for the market to mature, publishers and AI companies need better information about one another. We are investing in richer market intelligence, content signaling, and capabilities that improve discovery between both sides of the ecosystem, laying the foundation for more scalable market mechanisms over time.
One year ago, Content Independence Day introduced a simple idea: content owners should have greater control over how AI companies access and use their information.
Over the past twelve months, that control helped give rise to a market. Transparency created scarcity. Scarcity created leverage. Leverage accelerated licensing. What was once a theoretical discussion about the future of AI and content has become an active market, with publishers, AI companies, and technology providers all adapting to a new set of economic realities.
The market is now entering a new phase that demands new infrastructure. As the Internet becomes increasingly agentic, the underlying systems that support it must evolve to handle permissions, licensing, and commercial transactions at scale. Content owners and AI companies need more efficient ways to connect and exchange value. We believe these capabilities will converge into programmable, scalable mechanisms for content discovery and monetization – reducing friction while unlocking richer forms of value exchange.
Cloudflare’s role is to build the infrastructure and business intelligence, and contribute to the standards that allow the market to determine value more efficiently and help publishers and AI companies participate in a healthier, more dynamic content economy.
The Internet has always evolved. This evolution is faster and more consequential than most. But with the right infrastructure, the right incentives, and a commitment to transparency, we believe the agentic Internet can become more sustainable, more efficient, and better for everyone.
Methodology:
The data in this report is compiled from Cloudflare Radar and the Cloudflare Investor Day 2026 Presentation.
Cloudflare Radar is a hub showcasing global Internet traffic, attack, and technology trends and insights. Powered by data from Cloudflare’s global network, Radar was created to help anyone understand what is happening on the Internet from a security, performance and usage perspective.
Cloudflare’s unique understanding of the Internet comes from its global network — one of the world’s largest, spanning 330+ cities in 100+ countries — and aggregated and anonymized data from Cloudflare’s 1.1.1.1 public DNS Resolver, widely used as a fast and private way to browse the Internet. More than 20% of the web sits behind Cloudflare’s network.
Making AI search smarter
Post Syndicated from Matthew Conroy original https://blog.cloudflare.com/making-ai-search-smarter/
Search drives most experiences on the web. It’s how we get things done, and how nearly everything on the web gets found — the creators, the merchants, the answer to whatever you just typed into a box. For nearly 30 years, that discovery journey ran on a simple bargain: let a search engine crawl your content, and it sends you visitors. You turned those visitors into a business — through ads, subscriptions, or just the audience itself. Being discoverable and getting paid were the same thing. A year ago, on the first Content Independence Day, we drew a line to defend that bargain in the AI era. But a line in the sand was only a first step. Since then, the prevalence of AI search in consumers’ lives has only accelerated as more than 50% of traffic online is non-human. The threat is no longer a handful of training crawlers you can block; it’s search itself being rebuilt around AI answers.
Today’s answer engines read your page and hand the user a summary, so the visit — and the revenue that depended on it — isn’t needed. We see it firsthand, and independent research backs it up: a 2025 Pew Research Center study found that when Google shows an AI summary, users clicked on a traditional search result link just 8% of the time (about half as often as when there’s no summary) and clicked a link inside the summary only 1% of the time. That leaves our customers in a bind: opt out of AI and be hard to find, or opt in and deliver significant value to users while seeing increasingly little in return. Our customers want to be found and compensated for the value they provide, and right now they’re forced to choose.
Today, we’ve announced new bot options to help our customers better control who can access their site and what they can do with it. But blocking was only step one: saying “no” protects content without rebuilding the business models that sustain it. So, it’s time to start building the new economic model of the Internet, starting with search.
Transparency and control are the foundation, but more is needed. In 2025, we laid out our foundation via a set of responsible AI bot principles: bots should be transparent about who they are and what they’re for, respect site owners’ choices, and act in good faith. Our tools hold bots to that bar. But enforcing good bot behavior doesn’t make AI search any better for the people relying on it, and it doesn’t send a dollar back to the creator whose work made the answer possible. We can do more than help the web say “no”; we can help rebuild what it says “yes” to.
So today, we’re announcing two initiatives that move from defense to offense and start putting both halves of that old bargain back together.
Make AI search smarter: By using the signals we see across our global network, like what’s fresh, what’s high quality, and what’s actually changed, we can help answer engines surface the most relevant content and reduce unwanted crawling. People searching get better answers, while costs are reduced for both AI companies and site owners if webpages are only recrawled when they’ve changed.
Pay creators for the value they provide: When your work is used to answer someone’s question, you should be rewarded instead of just being scraped for free. And you should be able to see what’s being used and what people are asking. This should be a real revenue stream, and an incentive to keep producing original content worth finding.
Today we’re launching a research program to make AI search smarter and stop our customers footing the bill for crawls that produce nothing new.
More than 20% of the web sits behind Cloudflare’s network, which gives us a unique perspective. We can tell which pages have genuinely changed and which ones people and agents are flocking to. Through this program, we will explore using signals our customers have chosen to share about the freshness of their content, and we will combine those with our own insight into traffic flows, both human and bot. For answer engines, that’s a roadmap to high-quality content. For our customers, it provides a view of what users are actually asking, and how their content shows up in AI results. The aim is to measure two things: how much these signals help answer engines to surface fresher, higher-quality content, and how much unnecessary crawling they cut out.
That second benefit, cutting unnecessary crawling, is bigger than it sounds. Cloudflare data suggests that more than 50% of crawl traffic from good bots goes to re-fetching pages that haven’t changed — and that number is likely to climb as crawl volumes do. A signal that just says “nothing’s changed here” lets a crawler skip the trip. That saves the answer engine compute. More importantly, it saves site owners from serving and paying for requests they never needed to.
The program is neutral by design: our goal is to make it work for every answer engine willing to play fair. It’s limited to search. We aren’t sharing any content, and nothing is used to train foundation models. We intend to publish what we learn, including the benefits to site owners such as better content discoverability and reduced server strain. We plan to make the capability broadly available later this year and reduce unnecessary crawling across our network.
Last year we launched Pay Per Crawl so publishers could charge AI companies for crawling their content. It was a real start, but crawling is a crude measure of value. A single page might be crawled once and then cited in thousands of answers, or crawled over and over and never used at all. Creators want to be paid fairly for the value they provide.
So we’re starting to shape Pay Per Crawl into Pay Per Use. We’re running experiments with top AI companies, like Ceramic.ai and You.com, and the arrangement is straightforward: organizations can bring their payment models and easily scale them to content owners across the Cloudflare network.
Ceramic has built what it calls a “pay-per-query” model, so publishers who opt in can be paid when their content appears in Ceramic’s search results. This means payment is designed to follow the value the work delivers rather than the number of times a crawler happens to fetch it.
“To scale the future of AI search, we need a partner with massive reach and a shared commitment to transparency and fair compensation,” says Anna Patterson, founder and CEO of Ceramic.ai. “Cloudflare allows us to easily and programmatically scale our operations. By bringing our pay-per-query model to their network, we ensure millions of content owners can seamlessly opt in to be compensated every single time their content appears in our search results.”
In addition to compensation, content owners participating in the Cloudflare/Ceramic program will unlock new reporting to help with answer engine optimization (AEO). Customers can finally see the top queries leading to their content appearing in search results, the specific webpage and snippet, their average search result ranking position, and more. This is the first of many products we’ll be launching to help our customers with discoverability.
This is just one emerging approach. Another comes from You.com: agents can pay on demand for a specific piece of premium content they need, without any upfront commitment. New payment models from AI providers are being tested (e.g., Pay per Query, Pay per Result, etc.) and we have the infrastructure to support them all.
We want to be honest that this is an experiment. There’s a lot to learn, including exactly how this holds up at the scale of the Internet. We’ll work that out with our partners and our customers as we go, and share what we learn. But the goal is clear: AI search companies get fresher, better-grounded answers, and the customers whose work makes the answers possible get paid when they help. Cloudflare’s job in all of this is to provide the infrastructure layer that makes this market flourish.
We think this is a more natural fit for where the economics of search are heading. The old, human web optimized search to save time — providing excerpts, ten blue links, and a click. The agentic Internet is different: an agent can read fast and search continuously. Search is becoming something an agent does dozens of times to answer a single question, closer to a utility than a destination. In that world, the unit that matters isn’t the crawl or the click. It’s the outcome. Pricing the outcome, and paying the people who made it possible, is how the web continues to thrive.
A year ago on Content Independence Day, the headline was a default ‘no’: AI can’t crawl without compensation. This year, our focus is on giving our users more products and controls to say ‘yes’ and bring more benefits with it.
Today’s announcements are just the beginning. Cloudflare’s research project is designed to see if our signals produce better results with less crawling. Pay Per Use is a promising direction we’ll experiment with alongside partners who believe that content creators deserve fair compensation for their work. This is how the last 30 years of the web got built too: somebody runs the pilot that turns “the model is broken” into “here’s the new model,” one experiment at a time. We believe there’s value to our customers to be discoverable in this new agentic era, and to optimize their content for maximum discovery. But they should be able to do this without giving away their most valuable creative assets for free.
The web is changing, and the business models it’s relied on are changing with it. The old Internet was open, neutral, and worth contributing to. We have a rare chance to keep it that way, and to build the business models that fund it in the future. Smarter answers for humans and agents asking the questions. A fair deal for the people whose skill, creativity, and commitment makes the answers worthwhile. That’s how we pursue Cloudflare’s mission: to help build a better Internet.
Happy Content Independence Day!
Building on the open, agent-ready web? If you are interested in learning more about the Ceramic and You programs, please fill out this form. If you’re building an answer engine and want to crawl smarter, we’d love to hear from you too: [email protected].
