For most of the past decade, automated traffic fell into two definite groups. There were bots you needed, such as crawlers, integrations, and monitors. Then there were bots you wanted to block: scrapers, stuffing tools, and account farms. The control question was: allow or block.
But AI agents complicate the model; they utilize a large amount of information and operate using an identity your organization issued. Agent trust management addresses this by filtering traffic, governing identity, access, and accountability across various interfaces.
Here’s how you can give legitimate agents a controlled path while restricting them from unidentified or risky automation processes.
AI agent access control is the practice of determining which automated actors may reach a resource, what actions they may take, whose authority they are using, how long that access lasts, and what evidence they leave behind.
Traditional identity and access management often assumed a human at one end and a service account at the other. Service accounts were expected to be stable and predictable. Agents can select their next step, use several tools, and alter their actions based on retrieved information. WorkOS notes that this autonomy and tool chaining create access problems that traditional identity controls were not designed to address on their own.
Classic bot mitigation asks whether a visitor is human and whether its behavior appears abusive. That is no longer enough. A legitimate shopping or support agent is not human, but restricting it solely for that reason may prevent a valid interaction. An unidentified scraper, however, should not receive trusted access simply because it can run JavaScript or imitate a browser.
The practical question is therefore not just whether traffic is automated. Teams must know which agent is acting, who authorized it, what purpose it serves, and whether its current action fits that purpose.
Many agent incidents are familiar access-control failures triggered by more autonomous software. Common patterns include:
OWASP guidance stays relevant because agents often expose established weaknesses, including broken access control, inadequate logging, and unsafe handling of data or model output. Autonomy can make these weaknesses easier to trigger and tougher to investigate.
Policy design begins with a useful classification system. Cloudflare defines verified automation as traffic that identifies itself through methods such as signed requests or published IP ranges and behaves within stated rules. Its categories distinguish agent, search, and training activity. That distinction holds importance because each category may justify a different response. An organization might welcome search crawling, meter access by task-oriented agents, and restrict training collection.
It is also useful to distinguish direct agents from intermediary agents. A direct agent acts for a user or organization you can identify. An intermediary agent is operated by a third-party platform on behalf of many users. Trust in an intermediary is transitive because you are depending on the operator’s identity and abuse controls. That decision may need contractual terms and an explicit allowlist rather than a runtime guess.
CHEQ frames agent trust management as a process of classifying humans, bots, AI agents, and crawlers, assessing identity and intent, and then applying proportional controls across websites, apps, and APIs. Regardless of the tool utilized, that sequence provides a practical policy model: classify the actor, assess the request, and apply a response suited to the risk.
A durable agent control plane has four different jobs. Keeping them distinct makes each layer easier to test, monitor, and improve.
You cannot govern agents you have not catalogued. Each agent should have a unique identity, a named owner, an approved purpose, and a recorded set of tools and data sources. Google’s Gemini Enterprise Agent Platform defines an Agent Registry for cataloguing and governing agents, along with an Agent Gateway for controlled connectivity. Microsoft Entra Agent ID follows a similar approach by treating agents as first-class identities covered by access, governance, and protection policies.
Registries should also include agents embedded in third-party software. If an agent can analyze company data or take action on behalf of an employee, it belongs in the inventory even when another vendor operates the underlying service.
Role-based, attribute-based, and relationship-based rules still provide the foundation. Agent policies should also reflect purpose and data meaning, not just endpoints and technical permissions.
For example, a support agent may be allowed to decipher order records for the customer making a request. That does not mean it should be able to export every order record, even if the underlying API permits bulk access. The policy should limit both the type of data and the context in which the agent can use it.
Provisioning-time controls are not enough because permissions and behavior can shift. AWS guidance recommends distinguishing AI-driven actions from human-initiated actions in identity policies and restricting the resources an agent can reach. Tool and egress gateways provide enforcement points where teams can identify scope, destination, rate, and policy on each request.
Runtime controls should fail safely. If the system cannot check an agent’s identity or delegation chain, it should reduce access, require approval, or reject the request rather than silently grant broad permissions.
Every important action should be attributable to an agent identity, a delegating person or system, a policy decision, and a timestamp. Logs should also monitor the requested resource, the action taken, and whether human approval was required. Without that delegation chain, incident reviews become guesswork about who authorized an action and why it was allowed.
Okta’s guidance on least privilege for AI agents prioritizes four practical controls: give each agent a verifiable identity, grant short-lived and task-specific access, require human approval for high-risk actions, and govern the full lifecycle through decommissioning.
These principles also apply inside business applications. Zendesk, for example, documents role-based controls that allow administrators to determine which users may access particular AI agents. This is a reminder that agent governance is not just limited to cloud infrastructure. It also matters in SaaS products where agents can retrieve customer information, update records, or trigger workflows.
A useful default is to deny static access unless an agent needs it for a recurring and documented task. For temporary work, issue a token with the narrowest practical scope and a short expiration time.
Most organizations need controls at several layers rather than a single agent security product.
At the web, app, and API edge, the goal should be proportional control instead of a blanket ban. Verified agents can receive a defined access path with published limits. Unverified automation can be throttled, challenged, restricted, or blocked according to behavior and risk. Training collection should have its own guidelines. Robots.txt can communicate intent, but it does not enforce access.
Agent Trust Management from CHEQ is a single option for classifying automated visitors by identity and inferred intent, then applying controls across sites, apps, and APIs. When assessing CHEQ or another provider, ask how its classifications are validated, which controls can be tuned, how false positives are handled, and what evidence appears in audit logs.
Payments need additional controls because an agent may move from browsing to making a purchase. Visa’s Trusted Agent Protocol documentation describes verifying an agent’s message signature with its public key. Mastercard’s Agent Pay program similarly addresses agent-initiated payments across supported payment systems.
Merchant and platform teams must decide how much product and pricing data to expose, whether agents should utilize a distinct checkout flow, and how fraud systems should treat a signed agent compared with unidentified automation. They should also define when the buyer must acknowledge during the transaction and how refunds or disputes will identify the agent involved.
These decisions belong to product, security, payments, legal, and risk owners together. Edge controls can verify or classify traffic, but they cannot decide which purchases require customer approval.
You do not need a finished architecture to begin. Start with visibility, separation, and evidence.
NIST has explored how existing identity and authorization standards, including OAuth, OpenID Connect, and the Model Context Protocol, can help in agent identification, delegation, logging, and data-flow tracking. OWASP guidance provides a complementary view of application-layer risks. These resources are not substitutes for legal, privacy, or compliance advice, but they can help teams use consistent language when documenting controls.
Common mistakes include treating agents as extensions of user accounts, granting persistent access because precise scoping takes time, relying on CAPTCHAs as the main control, overlooking intermediary-operated agents, and failing to test decommissioning. That single-control habit is familiar from social engineering, where the organizations that lose most to phishing campaigns are often the ones depending on one filter rather than layered checks. Another frequent problem is collecting detailed logs without assigning anyone to review alerts or investigate unusual behavior.
Internal policy should clearly define who may approve an agent, who owns its credentials, which actions need human confirmation, how long logs are retained, and what happens when the agent’s owner changes roles or leaves the organization.
Agent trust arrives from several controls working together: a verifiable identity, policy that reflects purpose as well as permission, runtime enforcement, and records detailed enough to reconstruct a decision later. No single layer or product eliminates the need for the others.
Start with inventory, then separate agent identities from human accounts and narrow each agent’s access. Choose enforcement layers depending on where agents interact with your systems. That may include platform identity controls, an edge and API product such as the one CHEQ offers, or a combination. Review a small set of governance metrics each quarter so legitimate automation has a clear path and risky activity receives a proportionate response.
Bot management often focuses on determining whether traffic is human and whether it appears abusive. Agent trust management assumes some legitimate visitors are automated. It asks which agent is acting, who authorized it, and what it may do.
Start with identity rather than traffic analysis. AWS recommends distinguishing AI-driven and human-initiated actions in access policies. Give agents their own identities and record the delegating person or system.
Base the decision on behavior and purpose rather than the crawler’s label. Publish your position in robots.txt, but enforce it with identity checks and rate controls because robots.txt is advisory.
Treat intermediary agents as transitive trust. You are relying on the operator’s authentication and abuse controls rather than directly verifying the end user. Prefer signed identities, use an explicit allowlist, and apply separate scope and rate limits so investigators can attribute later actions.
