Protecting AI-agent endpoints

Agentic workflows have changed the shape of API traffic. Where a request once originated from a human clicking through a browser or a known first-party service, it now increasingly originates from an AI agent acting on a user’s behalf — planning a task, calling a tool, reading the response, and calling the next tool. From the application’s perspective, each of those tool calls is just another HTTP request hitting an endpoint. But the population making those requests, and the way it behaves, is fundamentally different from classic web or mobile clients.

That difference matters for security. An agent is software, so it is fast, tireless, and literal. It can retry on a tight loop, fan a single instruction out into hundreds of downstream calls, and follow an API contract far more aggressively than any human user would. Protecting endpoints that serve agents is therefore less about classic bot-versus-human heuristics and more about identity, intent, and rate: knowing which machine identity is calling, what it is allowed to do, and whether its behavior stays inside sane bounds.

Agents call APIs as machine identities

When an AI agent calls your API, it does not authenticate as a person. It authenticates as a non-human identity (NHI) — a service account, an API key, an OAuth client, or a workload credential issued to the agent or to the platform running it. These machine identities are the unit you actually need to reason about. A single human user might sit behind dozens of agent invocations, and a single agent platform might serve thousands of end users, so the human identity alone tells you very little about what a given request stream should look like.

Non-human identities also outnumber human ones, often by a wide margin, and they tend to be long-lived and broadly scoped. An API key minted for “the assistant” may be able to reach far more endpoints than any single task requires. That is exactly the kind of standing, over-provisioned access that turns a leaked credential or a confused agent into a real incident. Treating agent traffic seriously starts with treating the calling identity — not the endpoint — as the thing you enforce policy around.

The attack surface of agentic workflows

Agent-to-app traffic widens the attack surface in a few concrete ways. None of them are exotic; they are the familiar API risks, amplified by automation:

• Tool and API abuse. Agents are designed to call tools. If a tool is backed by a sensitive endpoint, an agent that is misdirected — by a malicious instruction, a poisoned data source, or simply a bad plan — can invoke that endpoint in ways the designer never intended.
• Excessive and runaway calls. A looping or retrying agent can generate request volume that looks like a denial-of-service event, exhausts rate budgets, and drives up cost. The traffic is often “valid” in the sense that each request is well-formed and authenticated, which is precisely what makes it hard to filter on payload alone.
• Broad, ambient authorization. When the agent’s credential can reach more than the current task needs, a single compromised or coerced agent inherits all of that reach. The blast radius is defined by the credential’s scope, not by the task.
• Classic injection at machine speed. Agent-generated requests can still carry the same SQL injection, command injection, path traversal, and malformed-input patterns that any HTTP client can — only now they arrive faster and in higher volume.

A point worth being precise about: a web application firewall sits at the HTTP layer and inspects requests and responses. It is the right place to enforce identity-aware access and abuse controls, and to apply established detection rules to request content. It is not a model-level guardrail. ArxLayer does not claim to detect prompt injection inside an agent’s reasoning, and no honest WAF should — that problem lives in the application and model layer, not on the wire. What a WAF can do is constrain what the resulting HTTP calls are permitted to do, and flag or block the ones that fall outside policy.

Identity-aware enforcement and abuse controls

The most effective controls for agent endpoints are the ones keyed to the calling machine identity rather than to a coarse client IP or a single global rate limit. Concretely, that means enforcement decisions that take the authenticated NHI into account:

• Per-identity rate and concurrency limits. Bound how fast and how heavily a given machine identity can call, so a runaway agent throttles itself instead of overwhelming the origin or draining a shared budget.
• Scoped access by endpoint. Make “this identity may call these paths and methods” an explicit, reviewable policy, so an agent credential cannot wander into endpoints outside its job.
• Anomaly-aware thresholds. Use anomaly scoring to separate a deliberate block from a borderline request, so legitimate agent traffic is not broken by an overly blunt rule.
• Evidence for every decision. Emit events for allowed, throttled, and blocked requests, attributed to the identity, so security teams can investigate abuse and tune policy with real data rather than guesswork.

The goal is enforcement that is proportional and accountable. Agents are legitimate clients; the objective is not to keep them out, but to keep each one inside the envelope it was provisioned for — and to make it obvious, quickly, when one steps outside.

Integrating machine identity with ArxLayer IAM / NHI

This is where ArxLayer IAM / NHI fits. ArxLayer treats identity for users, services, and machine identities as a first-class input to policy. When agent traffic arrives carrying a non-human credential, that identity can be used to select which rules and limits apply, so policy is attached to who is calling and not only to what they sent. That turns the four controls above from generic infrastructure settings into per-identity policy you can version, review, and roll back like any other change.

Because ArxLayer is API-first, those policies are managed as code. Domains, origins, and policies are API resources with immutable versions, so introducing a new agent integration — or tightening the scope of an existing one — is a reviewable, reversible change rather than a console edit nobody can audit later. As your agent footprint grows, that programmatic control plane is what keeps per-identity policy maintainable instead of sprawling.

Why OWASP CRS and enforcement help at the HTTP layer

Identity-aware limits answer “is this caller allowed to do this, this often?” They do not, on their own, answer “is this individual request malicious?” That is the job of the detection layer. ArxLayer Edge runs on the Coraza engine with the OWASP Core Rule Set — an open, community-vetted baseline for detecting common web and API attacks. Agent-generated requests are inspected with the same rules as any other HTTP traffic, and anomaly scoring with tunable paranoia levels lets teams move from detection to blocking deliberately, on evidence, without breaking legitimate calls.

Combining the two layers is the point. OWASP CRS gives you transparent, standard detection for the content of each request; identity-aware enforcement gives you proportional, per-NHI control over the rate and reach of the caller. Neither is a guarantee, and we will not pretend otherwise — but together they give security teams a credible, auditable way to govern the machine-to-machine traffic that agentic systems now generate.

One more architectural note that matters for agent platforms specifically: ArxLayer enforces traffic and holds no private keys. Certificate lifecycle and key custody live behind separate ArxLayer Certificate and ArxLayer Trust boundaries, and the WAF references certificates as opaque values it never resolves. For teams wiring agents into customer-facing endpoints across many domains, that separation keeps the enforcement layer’s blast radius bounded by design.

Bringing it together

AI agents are real clients generating real, authenticated, high-volume traffic against your APIs. The way to protect those endpoints is not a single magic filter; it is the disciplined combination of identity-aware enforcement keyed to the calling machine identity, abuse controls that keep runaway agents in check, and a transparent OWASP CRS detection baseline at the HTTP layer — all managed as versioned, reviewable policy. ArxLayer is built to do exactly that.