Blocking Agents Today, Preparing to Let Them In Tomorrow

Executive Summary

For businesses preparing to admit useful agents, integrating controls into the website and business application provides a better foundation for opening access than relying solely on edge-level blocking. The application can observe permitted interactions, distinguish between business actions, and introduce identity verification and authorization at the point where they become necessary.

Blocking unfamiliar agents today is a reasonable decision. The architectural question is whether that decision leaves a practical path to accepting authorized agents tomorrow.

• Prepare while you protect. Keep attack filtering and rate limits in place. Where business policy permits, allow bounded, low-risk activity and learn which agent use cases are worth supporting.
• Put business access decisions in the application. Browsing a catalog, reserving inventory, and changing a customer's order require different permissions. Website integration places those decisions alongside the relevant business context.
• Provide a path to establish or update authorization. When existing credentials do not satisfy an operation's requirements, the application can initiate identity verification and let the user configure the agent's permissions. Subsequent requests can reuse valid credentials carrying the required permissions, with the application checking access and business conditions on every request.

This is a recommendation about preparing for controlled access. Edge defenses continue to protect the infrastructure and can enforce suitable checks early.

Context: Block Now, but Choose an Integration That Can Open Later

If your team currently blocks unfamiliar bots and agents, we understand that decision. You are responsible for your website's availability, content, customer data, and business operations. You should not have to grant access before you can establish an acceptable basis for trust.

The next architectural decision deserves equal attention: how will you admit an agent when there is a business reason to do so?

For customer-facing businesses, the planning assumption should be that some agents will eventually represent customers you want to serve. An assistant may help someone compare products, manage an existing order, or complete an application. A policy that rejects those requests may be appropriate today, while the identity and authorization mechanisms are missing. It should also be possible to change that policy deliberately.

Preparing to open access starts with the integration choice you make while access is still restricted.

Today, two common patterns are available. They describe where detection, interaction, and enforcement are integrated; they are not an exhaustive classification of products.

Pattern 1: Controls in Front of the Website

In this pattern, a security service inspects requests before they reach the website's application servers. This is commonly called edge control, because the service operates on infrastructure in front of the application, often alongside a content delivery network, or CDN.

Cloudflare WAF and Bot Management are representative examples. AWS WAF Bot Control deployed with Amazon CloudFront is another. The service evaluates request information and configured policies, then allows, limits, challenges, or blocks the request. A challenge may appear before the visitor reaches the intended page. Rules can apply to particular paths rather than the entire site. Cloudflare bot protection rules, AWS WAF Bot Control

These services can also participate in identity verification. Cloudflare supports Web Bot Auth, which uses HTTP message signatures to verify the source of bot and agent requests. Cloudflare Web Bot Auth documentation

Pattern 2: Controls Integrated into the Website and Application

In this pattern, the website includes a detection SDK or verification component. Browser signals and interaction results are connected to the application's handling of particular requests.

hCaptcha and Foil are representative examples. hCaptcha can be embedded in a page or form, with the resulting verification token checked by the backend. Foil collects browser and behavioral signals, then provides a session token that the backend verifies before applying its policy to an operation such as signup or checkout. hCaptcha integration documentation, Foil server verification documentation

The integration spans both the page and the server. The page gathers signals or initiates an interaction; the backend decides whether the protected operation can proceed. A JavaScript check by itself is not the enforcement boundary.

A website can use both patterns. Edge products may collect browser signals, and website-integrated verification can supply evidence for edge enforcement. The distinction is the integration model, not a claim that each vendor operates in only one place.

Why Website Integration Provides a Better Path to Opening Access

Our recommendation is to make the website and business application the primary integration point for agent access that depends on user identity and delegated authority.

The advantage is practical: the application already manages the customer journey, the requested operation, and the business state. It can use that context to evolve a refusal into a supported verification path. Implementing the same workflow entirely at the edge requires those relationships and state to be connected there as well.

1. Understand Which Agent Workflows Are Worth Supporting

Opening access can begin with a limited surface: selected public information, bounded request rates, and no permission to change business state.

Within that surface, the website can connect detection signals with application events: a catalog search, an attempted reservation, or a request to modify an order. Those observations help the team identify which workflows agents attempt and where authentication or authorization becomes necessary. They provide evidence for deciding what to support next.

Google's reCAPTCHA v3 documentation recommends collecting context from both forms or actions and background page activity. Its named actions also support reporting and risk analysis for particular interactions. AWS recommends its application integration SDKs on critical pages such as login and checkout, and more broadly across dynamic pages to improve behavioral detection. Google reCAPTCHA v3 documentation, AWS Bot Control application integration guidance

These recommendations support the value of browser context. The application adds the business meaning: what was requested, whether it was eligible, and why it could not proceed. Combined with detection signals, those events can help distinguish demand for a useful workflow from repeated misuse. A risk score alone does not reveal an agent's purpose or prove user authorization.

The observation opportunity depends on what the site permits. Edge rules can also allow selected traffic, and a website that immediately blocks every interaction learns little about the subsequent journey. The advantage of website integration is the ability to connect permitted activity to business outcomes. AWS's combination of browser SDKs and WAF enforcement illustrates how the two integration patterns can work together.

This work belongs to website instrumentation, detection tools, and application analytics. Teams can collect useful evidence within a bounded public surface while keeping expensive queries, private data, and state-changing operations protected.

2. Define Access Requirements Around Business Operations

The next decision is what conditions an agent must satisfy for each operation. The application already understands the relevant account, resource, and business state, so it is a natural place to define those requirements.

This allows a team to open one capability while keeping others restricted. Recognizing an agent does not give it permission to perform every operation.

Business operations can map to predefined permission scopes. A user can grant an agent continuing access within selected scopes, and the application can check those permissions on subsequent requests. Checking authorization for each operation does not require asking the user to approve each operation again.

hCaptcha's Agent Controls page gives a concrete example: an assistant can browse a catalog but must complete verification before reserving inventory. It also places verification and business checks at each protected backend endpoint. That supports applying different policies to different actions; a bot-verification token does not by itself establish the customer's delegated permission. hCaptcha Agent Controls

Some requirements depend on state that a URL alone cannot express. A request to modify an order may need proof of customer identity and delegated authority, but the application must also check ownership and whether the order has already shipped. A process involving verified personal information may require additional identity evidence.

RFC 9470 provides a useful precedent for this division of responsibility. Its e-commerce example lets the API's transaction logic determine that stronger or more recent authentication is necessary, then communicate that requirement to the client and authorization server. The application sets the requirement; the identity service establishes the proof. RFC 9470: OAuth 2.0 Step Up Authentication Challenge Protocol

Edge rules can distinguish paths and enforce suitable checks. Website integration becomes especially useful when access depends on business state, user relationships, and delegated permissions already managed by the application. It keeps the decision about opening a capability alongside the logic that governs that capability.

3. Turn a Block into a Verification-and-Resume Flow

When existing credentials lack the required identity evidence or permission, the website can explain the requirement, retain the pending operation, and provide a path to establish or update authorization. Requests already covered by valid credentials can proceed to the application's business checks without repeating that flow.

A challenge inserted into an arbitrary request can disrupt that process. Cloudflare documents that its interstitial Challenge Pages return HTML, which is incompatible with requests expecting a non-HTML response, such as an AJAX or fetch call. For these situations, it recommends integrating Turnstile Pre-clearance into the page before protected API access. This illustrates why verification needs to fit the application's interaction model. Cloudflare Challenge Pages compatibility limitations

For an address change, for example, the application can hold the operation while the user reviews the agent's permission to modify delivery details. Once the required permission is enabled and the identity requirements are met, the application checks the credential and the order's current eligibility. The granted permission can also cover later eligible requests. A verification service manages identity and permission settings; the website preserves and completes the business task.

Edge platforms can also redirect requests and support custom workflows. The application-side advantage is that the account, pending action, and business state are already present in the system coordinating the interaction. The website can turn a refusal into an explicit route to obtaining the missing proof.

Opening Access with AIGW

AIGW is an identity verification and authorization service for websites serving agents that act on behalf of users. It supports mainstream agent verification methods, authenticates the user, and establishes delegated permissions. Where needed, it also verifies real-world identity attributes such as a name, address, or date of birth.

Ongoing Access Through Predefined Scopes

Users choose which predefined scopes to enable or disable for an agent. The token reflects those selections, which govern continuing access until the user changes them. Changes are reflected in updated tokens.

This is ongoing delegation, not a single-use approval for one transaction. A valid token can be reused across eligible requests; its expiry is separate from the user's continuing permission settings. A user could, for example, enable order reading while leaving delivery changes disabled.

The Integration Pattern

1. The website identifies the requirements. The application maps the requested operation to the required scopes and identity evidence. If valid credentials already satisfy them, it proceeds to its business checks.
2. The website initiates the AIGW flow when needed. If identity evidence is missing or the user wants to change permissions, the website directs the verification and authorization flow to AIGW while preserving the pending task. AIGW handles the required identity checks and the user's scope selections.
3. The application checks access and continues. It validates the token and required scopes, checks resource ownership and current business conditions, and executes the operation only when all requirements are met. Later requests can reuse valid credentials without repeating user approval.

For example, enabling a delivery-change scope can permit an agent to update eligible orders going forward. The application still determines whether each order belongs to the user and can be changed. If the required scope remains disabled, the operation stays blocked.

Website instrumentation and detection tools provide behavioral visibility; AIGW provides identity and authorization evidence. The application enforces permissions on every protected request, consistent with OWASP's authorization guidance.

Edge defenses continue filtering attacks and limiting traffic alongside these application controls, consistent with OWASP's layered bot-defense guidance.

Start with one useful capability. Website integration gives the team a place to establish the required trust, respect the user's continuing choices, and expand access deliberately.

References

Sources checked on October 27, 2026; reference 11 was updated and checked on October 28, 2026. The sources support the specific capabilities and integration guidance cited above. The recommendation to coordinate business access in the application is our architectural assessment.

1. Cloudflare. Custom rules. See “Path-specific protection,” “Custom actions,” and “Forwarding bot data to origin” for granular edge policies and the ability to share detection signals with an application.

2. Amazon Web Services. AWS WAF Bot Control. Describes CloudFront deployment, request-level bot visibility, configurable responses, and custom application workflows.

3. Cloudflare. Web Bot Auth. Describes verification of bot and agent request provenance through HTTP message signatures.

4. hCaptcha. Developer Guide. See “Add hCaptcha to your site or app” and “Verify the token on your server” for the browser-component and backend-verification integration pattern.

5. Foil. Server verification. Describes early browser initialization, a fresh session-token handoff before sensitive actions, and backend verification and policy enforcement.

6. Google. reCAPTCHA v3. See “Placement on your website,” “Interpreting the score,” and “Actions” for background context collection, observation before enforcement, and action-specific analytics and risk assessment.

7. Amazon Web Services. Using application integration SDKs with Bot Control. Recommends SDK integration on critical pages and across dynamic content, and explains how browser-derived tokens improve WAF session analysis.

8. hCaptcha. Agent Controls: Detect and Manage Agents. Describes catalog browsing versus inventory-reservation verification, session visibility, and application enforcement at protected endpoints. It also distinguishes request provenance from access permission.

9. Bertocci, V., and Campbell, B. RFC 9470: OAuth 2.0 Step Up Authentication Challenge Protocol. IETF, September 2023. Sections 1 and 2 describe resource-driven authentication requirements and the subsequent authentication-and-retry flow.

10. Cloudflare. Interstitial Challenge Pages — Compatibility limitations. Documents the HTML-response limitation for AJAX/fetch requests and recommends Turnstile Pre-clearance for those integrations.

11. OWASP. Authorization Cheat Sheet. See “Validate the Permissions on Every Request” and “Verify that Authorization Checks are Performed in the Right Location” for repeated permission checks and server-side enforcement.

12. OWASP. Bot Management and Anti-Automation Cheat Sheet. “Layered Defense Architecture” recommends combining edge, application, and backend/business controls.