Frequency:Common
An agent's tool permissions are computed by inheriting from a parent context — the invoking user's role, the calling service's credentials, or a parent agent's session — rather than being independently assigned. When the inheritance logic doesn't map cleanly (e.g., a support agent inherits an admin's broad scope because the admin happened to trigger the workflow, or a background job inherits a service account's org-wide scope instead of the specific user's narrower one), the agent ends up with either far more access than the task requires or, less often, too little to complete legitimate work.
Frequency:Occasional
In a multi-tenant SaaS product, a tool call made on behalf of one customer account is scoped using the wrong tenant/account identifier, causing the agent to read or write data belonging to a different customer entirely. This typically happens when the account ID is derived from a stale cache, a URL/session parameter that wasn't re-validated, or a default value used when the true tenant context is missing from the request.
Frequency:Common
Some tool vendors don't publish a fixed rate limit at all — instead they throttle dynamically based on backend load, shedding traffic more aggressively during peak hours or incident windows. An agent that learned "this API allows ~50 requests/minute" from yesterday's behavior has no way to know that the vendor has silently tightened the effective limit to 10 requests/minute right now, so it keeps firing at its old cadence and racks up a string of 429s it can't explain.
Frequency:Common
An agent exposes admin-tier tool operations (e.g. `delete_user`, `override_billing`, `reset_org_settings`) through the same tool-calling interface as ordinary operations, and the dispatch layer invokes them without first checking whether the requesting user actually holds an admin role. Any user who can phrase a prompt that maps to the admin tool schema gets the admin code path executed with the agent's (often elevated) service credentials.
Frequency:Common
An agent authenticates to a tool using a shared account-level API key, and that key's quota (requests/minute, tokens/day, credits/month) is pooled across every consumer that happens to use it — other agents, human users, cron jobs, and staging environments. The agent has no visibility into who else is drawing down the same quota, so it plans its own call volume as if it owned the full allocation, then gets throttled or rejected by calls it never made.
Frequency:Occasional
A high-risk action (fund transfer, policy override, data export) is gated behind a requirement that a human approver's cryptographic signature or signed token accompany the execution request. The agent's verification of that signature is incomplete — it checks presence of a token rather than validity, uses a weak or non-constant-time comparison, doesn't bind the signature to the specific action payload, or doesn't check expiry/single-use — so a forged, replayed, or mismatched approval is accepted as genuine.
Frequency:Common
Many tool APIs cap the number of elements allowed in a specific array field of a single request — for example a maximum of 500 line items per invoice-creation call, or 1,000 IDs per bulk-lookup request. When an agent assembles this array dynamically (aggregating results from a prior tool call, paginated upstream source, or a loop that accumulates records), it frequently has no visibility into the cap until the call fails or, worse, the API silently truncates the array and returns success. The agent then proceeds as if all elements were processed, producing incomplete work that looks complete.
Frequency:Common
Many APIs specify an expected retry envelope for failed requests — a minimum delay before retrying (to avoid hammering a recovering service) and a maximum delay (beyond which the server considers the client "gone" and drops queued state, such as an idempotency reservation or a rate-limit grace window). An agent's retry logic, especially generic exponential-backoff code reused across many tools, frequently ignores tool-specific envelope hints (a `Retry-After` header, a documented min/max, or a jittered range) and either retries too fast — getting throttled harder or banned — or waits too long — missing a narrow retry window and losing queued work or an idempotency token.
Frequency:Very Common
Bulk-operation tools commonly enforce a maximum number of operations (rows, records, actions) per batch request, distinct from any single-field array cap — for instance a max of 200 records per bulk-import call or 100 messages per batch-send. Agents that build a batch from dynamic upstream data (a database query, a paginated feed, a fan-out from a previous step) often assemble the request first and only discover the limit when the call is rejected outright, because nothing in the agent's planning path checks the batch's total size against the tool's documented ceiling before dispatch.
Frequency:Common
Beyond the size limit on any single batch, many tools also enforce an aggregate cap on total operations across a rolling window — for example, no more than 10,000 record writes per hour regardless of how they're split across individual batch calls. An agent that correctly chunks each batch to stay under the per-call limit can still violate this rolling aggregate cap if it fires many compliant batches in quick succession, because per-call compliance says nothing about cumulative volume over time. The agent's batching strategy solves the wrong constraint and the job fails partway through with no signal that the two limits are independent.
Frequency:Occasional
A tool exposes a "computed" or derived field — one assembled on the fly by joining, aggregating, or inferring across multiple underlying sources (e.g., a `customer_risk_score`, `estimated_lifetime_value`, or `inferred_household_income` field) — but the field's metadata doesn't flag it as either sensitive or expensive to compute. Because the access-scoping layer typically makes decisions based on static field metadata (classification tags, cost annotations), an unflagged computed field slips through with no gate at all, and the agent queries it as freely as any plain stored column.
Frequency:Common
Many SaaS tools license access by concurrent "seats" or "sessions" rather than by request volume. When an agent authenticates as if it were a human user — holding a persistent session or logging in under a shared service account — it consumes one of those concurrent slots. This either locks the agent out when human users have filled the pool, or worse, silently evicts a human user's active session when the agent logs in and the license enforces a hard cap.
Frequency:Common
Some permissions are conditional on runtime state rather than static role membership — "allow withdrawal only if account balance exceeds the requested amount," "allow this API call only during business hours," "allow escalation only if the ticket is marked P1." The agent evaluates these conditions against stale, cached, or incorrectly fetched data, or implements the comparison logic incorrectly (off-by-one, wrong field, wrong currency/unit), and grants access that the live condition would have denied.
Frequency:Common
An agent's HTTP client (or the SDK wrapping a tool) maintains a fixed-size connection pool, typically sized for a single-threaded request/response app rather than an agent fanning out dozens of parallel tool calls. When the agent spawns concurrent sub-tasks that all hit the same tool, requests queue up waiting for a free connection from the pool and start timing out or erroring — even though the remote API itself has plenty of headroom and would happily serve the traffic.
Frequency:Very Common
A tool call's underlying TCP/TLS connection times out — a transient blip caused by network jitter, a brief DNS hiccup, or a momentary vendor load spike — and the agent has no retry logic wrapping the call. Instead of treating the timeout as a one-off, recoverable event, the agent surfaces it as a hard tool failure: it aborts the current task, marks the tool "unavailable," or hands the user a generic error, even though a second attempt a moment later would very likely have succeeded.
Frequency:Common
A tool executes agent-submitted work as a job (e.g., a serverless function, a batch data-processing task, a sandboxed code-execution call) under a fixed CPU quota — a cgroup limit, a vCPU-second cap, or a throttling policy. When the agent's request involves more computation than expected (a larger dataset, an unexpectedly expensive query plan, a recursive operation), the job gets throttled mid-execution or killed outright by the orchestrator, and the agent receives a generic failure with no indication that CPU exhaustion was the cause.
Frequency:Common
Records or fields are tagged with a sensitivity classification (e.g., `public`, `internal`, `confidential`, `restricted`) in the data catalog, but the tool-serving layer the agent calls through doesn't actually check that classification before returning results. The classification exists as documentation and governance metadata, not as a runtime enforcement rule, so an agent with generic tool access retrieves `restricted`-tagged data exactly as easily as `public`-tagged data.
Frequency:Common
An agent scoped to operate within a specific business boundary — a department, project, or team — issues a tool query that crosses into a sibling boundary it was never intended to see, because the boundary is a soft, business-logic construct rather than a hard constraint enforced at the tool layer. Unlike multi-tenant or workspace isolation, these boundaries usually live inside a single shared database and account, distinguished only by a filter (e.g., `department = 'Engineering'`) that the application is expected to apply consistently but doesn't always.
Frequency:Common
A user grants an agent limited authority to act on their behalf — e.g. "book travel under $2,000" or "respond to routine emails but don't send anything financial." The agent (or a sub-agent it spawns to handle part of the task) continues acting under the user's identity or impersonation token beyond that delegated scope, because the scope was expressed as a natural-language instruction rather than an enforced, machine-checkable boundary on the credential itself.
Frequency:Very Common
A tool enforces a hard maximum execution time per call (a Lambda-style 15-minute cap, a synchronous API's 30-second gateway timeout, a query engine's statement timeout). When the agent issues a request whose natural completion time exceeds that ceiling — a large data export, a bulk transform, a long-running search — the call is killed at the boundary with no partial results returned and often no clear indication that a timeout, rather than a crash, was the cause.
Frequency:Very Common
Text fields in most APIs have a maximum length — a ticket description capped at 4,000 characters, a product title capped at 200, a commit message capped at 72 characters for the summary line. When an agent generates the content for such a field with an LLM (a summary, a composed message, a generated description), the output length is not guaranteed to respect the target field's limit, since the generation step and the submission step are typically decoupled. The tool either rejects the write outright or, more insidiously, silently truncates the string mid-word or mid-sentence, producing corrupted or nonsensical stored content that the agent has no way of detecting from a success response alone.
Frequency:Very Common
A table or record type has some fields an agent should be permitted to see (e.g., order status, ticket subject) and others it shouldn't (e.g., internal margin, a customer's raw payment token), but the access-control system was built to grant or deny access at the record level only. Once an agent is authorized to read a record at all, every field on it — including the ones that were never meant to be exposed to that agent or context — comes along for free, because there's no enforcement point that operates below record granularity.
Frequency:Occasional
Data subject to geographic access or residency restrictions — most commonly EU personal data under GDPR, but also sector-specific rules like data-localization laws — is returned to an agent whose processing, storage, or invoking context sits outside the permitted region. This happens when the tool layer checks whether the requester is authorized in a general sense but doesn't verify that the specific data-residency or cross-border-transfer condition is also satisfied for that particular request.
Frequency:Common
A role is defined with fine-grained access — e.g. "read-only" or "can create tickets but not delete them" — but the tool wrapper the agent calls exposes the underlying API's full create/read/update/delete surface regardless of which operations the role is actually meant to permit. The agent, having no operation-level gate in the tool itself, can invoke update or delete through a tool nominally scoped to a narrower capability.
Frequency:Common
Query tools built on relational or graph data — GraphQL APIs, ORM-backed REST query endpoints, relational-API query builders — commonly cap how many joins or nested relations can be traversed in a single query, for example a maximum of 5 levels of nested relations. An agent that dynamically constructs a query to satisfy a broad information-gathering goal (e.g., "get the order, its customer, their company, the company's account manager, and that manager's team") can easily exceed this depth without realizing it, especially when the query is assembled programmatically by chaining relation names rather than authored by a person who would naturally notice the query getting unwieldy.
Frequency:Common
A field is designed to be masked or redacted before it reaches an agent — for example, a credit card number shown as `
Frequency:Common
A tool caps the memory available to a single operation (a container memory limit, a serverless function's configured RAM, an in-process buffer ceiling). When the agent sends a request whose payload or intermediate working set exceeds that ceiling — a large file upload, a wide JSON response being deserialized in full, a big in-memory join — the operation is killed by an out-of-memory (OOM) reaper and the failure surfaces to the agent as an opaque, non-specific error rather than a clear "payload too large for allocated memory" message.
Frequency:Occasional
Many tools reject JSON or other structured payloads once object/array nesting exceeds a fixed depth — commonly somewhere between 10 and 32 levels — to protect their parsers from stack-exhaustion and pathological-input attacks. Agents that build payloads through recursive composition (e.g., chaining tool outputs into a nested config object, recursively expanding a tree-shaped data structure, or composing several sub-tool results into a wrapper object) can produce structures that grow deeper than intended without any single step looking unusual, because the depth accumulates across composition steps that the agent reasons about independently rather than as a whole.
Frequency:Very Common
Before performing a mutating action on a specific resource (cancel this subscription, delete this file, update this profile), the agent authenticates that a valid user is making the request but never verifies that this specific user is the owner or authorized party for this specific resource. Any authenticated user can therefore direct the agent to mutate resources belonging to someone else simply by supplying that resource's identifier.
Frequency:Common
A tool enforces a short-window burst limit (e.g., no more than 5 requests in any 1-second window) that is much tighter than its sustained rate limit (e.g., 300 requests/minute). An agent orchestrating parallel sub-agent fan-out — say, dispatching 15 research sub-agents that each immediately call the same search tool the instant they spawn — blows through the burst ceiling in the first second even though the resulting sustained average is comfortably under the per-minute quota.
Frequency:Common
A tool's backend enforces a hard cap on the number of simultaneous open connections per account or API key (common with database connectors, legacy SOAP/XML-RPC services, and some SaaS APIs built on connection-oriented protocols). When an agent's orchestrator executes multiple sub-tasks in parallel, each holding open its own connection to the same tool for the duration of a long-running call, the agent can open more concurrent connections than the vendor allows — and unlike a request-rate limit, this failure mode has nothing to do with how many requests per second are being sent, only how many are open at once.
Frequency:Common
A tool rejects any request beyond N simultaneously in-flight requests per account, regardless of connection count or overall request rate — a request-level concurrency cap rather than a connection-level or rate-based one. An agent orchestrator that dispatches parallel tool calls without an explicit concurrency throttle routinely exceeds this in-flight limit during fan-out, causing a wave of immediate rejections that has nothing to do with total volume or open connections.
Frequency:Very Common
A tool enforces a hard daily request quota (e.g., 1,000 calls/day on a free or standard tier), and the agent has no visibility into how much of that quota remains as the day progresses. Because the agent paces its usage without any remaining-quota signal, it can burn through the full day's allotment in the first few hours of heavy activity, leaving the tool completely unavailable for the remainder of the day regardless of how important later calls are.
Frequency:Very Common
A tool enforces an hourly request quota, and an agent whose usage is bursty within the hour — heavy activity in a 10-minute window followed by relative quiet — exceeds the hourly cap even though its average request rate across the full day is well within budget. Unlike a daily quota, the hourly window resets often enough that the failure is usually short-lived, but frequent enough (potentially every hour) to meaningfully degrade throughput if the agent's traffic pattern is inherently spiky.
Frequency:Very Common
A tool enforces a per-minute rate limit, and the agent hits it during a tight retry loop: an initial call fails or is slow, the agent retries immediately without backoff, and each retry itself consumes another slot against the same per-minute budget — compounding the original problem instead of resolving it. What starts as one transient failure turns into a cascade of rate-limit rejections that persists well past whatever caused the first failure.
Frequency:Common
Permissions in a hierarchical system are meant to narrow as they cascade down (an org-level admin has broad rights, a team-level member has fewer, a specific user within that team has only what's explicitly granted), but the agent's logic for resolving effective permission at a given level applies the wrong tier's rules — either inheriting a broader ancestor permission that should have been narrowed, or failing to inherit a permission that should have propagated down, resulting in over- or under-granted access.
Frequency:Very Common
A tool call returns personally identifiable information (name, email, phone, home address, date of birth) that wasn't necessary for the task the agent was performing and wasn't supposed to be exposed to that agent or context at all. Unlike a masking or classification failure, the PII here isn't hidden behind any control — it's simply present in the default response shape of a tool because the tool was designed to return "the whole object" rather than the minimum fields the task requires, and the agent (and anything downstream of it, including logs and conversation history) now has that PII whether it needed it or not.
Frequency:Common
PII is correctly scrubbed or redacted from a tool's primary, well-tested response path, but leaks through a secondary channel the same tool call touches — an error message that echoes back invalid input, a stack trace surfaced when a downstream call fails, a nested or joined object included for context that wasn't covered by the redaction filter, or a debug/verbose field left enabled in production. The agent then reads that secondary channel as part of its normal error-handling or context-gathering behavior and surfaces the leaked PII to the user, having no way to know it wasn't supposed to be there.
Frequency:Occasional
Query tools that support flexible field selection — most notably GraphQL APIs — often score each incoming query for computational cost (a function of field count, list multipliers, and nesting) and reject any query above a threshold, independent of raw depth or byte size. An agent auto-generating a query to fulfill a broad request ("get me everything about this customer") can easily construct a query that is shallow and small in text but scores extremely high in complexity, because a handful of fields that each return large lists multiply together into a cost the agent has no way to estimate from the query text alone.
Frequency:Occasional
Before a complex query ever executes, the tool's query planner (a database optimizer, a GraphQL resolver-planning phase, a distributed-query coordinator) has to determine an execution strategy — and for sufficiently complex queries, this planning phase itself can time out, independent of and prior to any execution timeout. This produces a distinct failure class from an execution timeout: the query never ran at all, no partial work was done, and no rows were touched, yet the error returned to the agent often looks identical to a generic timeout, so the agent's error handling treats it the same as a slow-but-progressing query and applies the wrong recovery strategy.
Frequency:Occasional
Multiple instances of an agent (or multiple sub-agents sharing one API key) send requests right around a quota window's reset boundary, and because clock synchronization between the agent fleet and the vendor's rate-limit accounting is imperfect, the enforcement becomes inconsistent at exactly the moment it should be cleanest: some requests sent a few milliseconds before the reset are counted against the new window, some sent a few milliseconds after are still counted against the old (exhausted) one, and different agent instances observe different outcomes for functionally identical timing.
Frequency:Occasional
A single logical operation — a multi-step workflow, a paginated data pull, or a batch job that makes many sequential tool calls — spans a quota reset boundary partway through. The calls made before the reset count against the old window, the calls made after count against the new one, and because the agent tracks the operation as one atomic unit but the vendor tracks quota in two disjoint windows, the two views of "how much budget is left" fall out of sync mid-operation, sometimes causing the tail of the operation to fail even though a fresh reset "should" have provided plenty of headroom.
Frequency:Common
A tool enforces a quota (daily, hourly, or otherwise) but the vendor does not precisely document when the window resets — the docs might say "resets daily" without specifying a time zone, or "rolling window" without specifying the exact rolling mechanism. Without a precise reset time, the agent cannot safely schedule retries or backoff near the boundary: it either retries too early (wasting an attempt against a still-exhausted quota) or waits too conservatively long (leaving the tool idle for extra time after it actually became available again).
Frequency:Common
Some tools enforce rate limits with zero grace period: the moment a request is rejected with a 429, the very next request — even one sent a fraction of a second later, even one that would normally be well within budget — is also immediately rejected, with no brief cooldown signal or soft-warning phase before the hard cutoff. Agents that respond to the first 429 by retrying quickly (assuming a brief backoff is enough) get rejected again immediately, and if their backoff strategy isn't tuned for a limit with no forgiveness, this produces a tight loop of rapid-fire failures instead of a clean recovery.
Frequency:Very Common
A tool returns standard or vendor-specific rate-limit headers on every response (e.g., `X-RateLimit-Remaining`, `X-RateLimit-Reset`, `Retry-After`) that would let the agent pace itself proactively and avoid ever hitting a hard rejection — but the agent's HTTP client or tool wrapper doesn't parse or act on them. The agent keeps calling at its own fixed cadence until it eventually gets rejected outright, throwing away information the vendor was actively handing it for free.
Frequency:Common
An agent is deliberately provisioned with read-only access to a data source — the intent being it can look things up but never modify anything — yet a misconfigured tool binding, an overly broad service credential, or an undocumented fallback code path still allows write operations to succeed. The read-only boundary exists in configuration or documentation but isn't actually enforced at the point where the write would occur.
Frequency:Very Common
An agent is correctly granted access to a tool or table in general — it's allowed to call "get ticket" or "list documents" — but the underlying implementation doesn't check whether the specific record being requested actually belongs to, or is otherwise authorized for, the requesting user or context. Because the tool-level grant is real and the agent is "supposed" to be able to use this tool, the missing per-record ownership check is easy to overlook: every individual call looks legitimate, and only in aggregate does it become clear the agent can read (and sometimes write) any record in the table, not just the ones it should.
Frequency:Common
Before executing a write, update, or delete via a tool, the agent doesn't verify that the current user is actually the owner of, or otherwise authorized to modify, the specific record being targeted. The write succeeds because the tool checks that the agent/user has general permission to call the "update" endpoint, but never re-confirms that the particular record ID supplied belongs to that user — turning a routine "update my profile" or "cancel my order" request into a capability to modify anyone's record, simply by supplying a different ID.
Frequency:Very Common
Tools commonly cap the total byte size of a single request — a common ceiling is 1MB, 6MB, or 10MB depending on the platform — independent of any per-field or per-item limits. An agent that builds a request body from accumulated context (conversation history, retrieved documents, concatenated tool outputs, embedded file attachments) can exceed this ceiling even when every individual field is reasonable in isolation, because the agent's context-accumulation logic tracks relevance and completeness, not cumulative serialized byte size against the specific tool being called next.
Frequency:Common
Some tools enforce a hard request timeout with no partial-result mechanism: if the operation isn't fully complete when the clock runs out, the connection is simply dropped and any work done up to that point is discarded rather than returned. An agent that issues a single long-running call (a large data export, a bulk transformation, a synchronous report generation) against such a tool loses all progress when the timeout fires, and — because the response is indistinguishable from other connection failures — the agent typically retries the entire operation from scratch rather than recognizing that the work needs to be restructured into smaller, checkpointable steps.
Frequency:Common
Tools that return large result sets — search results, exports, list endpoints without server-driven pagination — often cap or silently truncate the response payload above a certain size, and critically, this truncation frequently happens without a clear error or a truncation flag in the response body. An agent that reads such a response, parses whatever JSON or text made it through, and proceeds treats a partial result as the complete answer, leading to decisions, summaries, or downstream actions based on missing data with no indication anything was cut off.
Frequency:Common
An agent is assigned a role intended to convey a specific level of access (e.g. "support-tier-1"), but the mapping from that role to the underlying tool's actual permission model is incomplete, outdated, or was translated incorrectly during integration — so the agent ends up able to do meaningfully more, or less, than the role's name and documentation suggest. Unlike a missing check, the check exists and runs; it's the mapping table itself that's wrong.
Frequency:Common
The agent's pacing logic assumes a tool's quota resets at a fixed clock boundary, when the tool actually enforces a rolling/sliding window that never resets all at once. Quota consumed at any given moment doesn't free up until exactly that much time has elapsed since it was consumed, continuously, rather than all at once at a fixed reset point. Because the agent's scheduling strategy is built around a reset-and-refill mental model, it either waits far longer than necessary for capacity to return, or assumes capacity is available at a "reset time" that doesn't actually exist for a rolling window.
Frequency:Occasional
A delegated or sub-agent spawned by a parent agent is designed to receive a narrower permission scope than its parent — for example, a research sub-agent that should only have read access to a specific document set, spawned by an orchestrator agent with broad workspace access. But the mechanism that's supposed to enforce that narrower scope (a new, restricted credential; a filtered tool set; a scoped session token) either isn't actually applied or is applied only cosmetically, so the sub-agent retains the parent's full underlying access even though its declared, intended scope is much smaller.
Frequency:Common
Fields that are explicitly flagged in policy as sensitive — salary, health status, disability accommodations, immigration status, background check results — are technically accessible through a tool with no additional authorization check beyond the baseline permission to use the tool at all. The sensitivity flag exists as a governance label describing how the field *should* be handled, but no runtime gate (step-up authentication, role-specific approval, purpose limitation) actually stands between an agent and the field once it has ordinary access to the record it lives on.
Frequency:Very Common
An operation is classified in policy as sensitive or high-risk — deleting a production resource, transferring funds above a threshold, changing a customer's access level — and is documented as requiring human approval before execution. In practice, the agent's execution path has no code-level gate enforcing that requirement: the classification exists as a label or a line in a policy document, but nothing in the tool-dispatch pipeline actually blocks execution pending approval.
Frequency:Very Common
An agent writes data through a tool — uploading files, storing generated embeddings, persisting logs or artifacts — and the underlying account or bucket has a fixed storage quota that the agent has no visibility into until it's already been exceeded. The write fails at the moment of the overage, often mid-batch, with no prior warning that the quota was approaching, leaving the agent with a partially-written dataset and no clean way to know which records succeeded.
Frequency:Common
Multiple instances of an agent (or multiple distinct agents in a fleet) write to the same pooled storage quota — a shared object store bucket, a shared vector database namespace, a shared scratch volume. One agent instance with an unusually heavy workload (large file uploads, verbose logging, an unbounded caching pattern) can silently consume the entire pool, causing unrelated agent instances to fail their own writes with no indication that another agent, not their own behavior, caused the exhaustion.
Frequency:Occasional
A storage tool enforces a soft limit below its hard quota ceiling — triggering throttled write speeds, forced read-only mode, or reduced replication guarantees once usage crosses a threshold like 85% of provisioned capacity. The agent has no logic to detect this intermediate degraded state; it only recognizes "working" versus "hard error," so when writes start silently slowing down or getting rejected in read-only mode, the agent misattributes the behavior to a bug in the tool, a network issue, or its own code, rather than recognizing an approaching-capacity condition it could act on.
Frequency:Occasional
Access to certain data is supposed to be restricted to a temporal window — only during business hours, only for a fixed number of days after an event (e.g., 30 days after an employee's termination, or 90 days after a transaction for fraud review), or only before a record's scheduled expiration — but the tool that serves the data has no check against the current time relative to that window. The data remains fully queryable indefinitely, or outside the intended hours, because the temporal restriction was defined as a policy rule rather than implemented as a runtime condition on the query path.
Frequency:Common
Some tools — especially LLM inference APIs and other usage-metered services — rate-limit by consumed tokens or compute units rather than by raw request count (e.g., "200,000 tokens per minute" instead of "500 requests per minute"). An agent whose rate-limiting logic only tracks how many requests it has sent has no visibility into token consumption, so it can stay well under any request-count budget while still blowing through the token-based limit, especially when individual calls vary wildly in size (a short classification prompt vs. a long document-summarization prompt).
Frequency:Occasional
Some tools track retry attempts server-side per operation (keyed by an idempotency key, request ID, or resource ID) and permanently block further retries once a maximum attempt count is reached within a window — for example, a payment gateway that hard-fails an idempotency key after 5 attempts, refusing all further retries regardless of the reason for prior failures. An agent's own retry counter, especially one held in process memory or reset on deploy/restart, frequently loses sync with this server-side count, so the agent believes it has budget for more attempts and keeps retrying into a wall that will never open, wasting time and obscuring the real failure behind a misleading "max retries exceeded" or generic error each time.
Frequency:Common
Multi-step tool jobs (a batch pipeline, an orchestrated workflow, a long-running export composed of several sequential API calls) frequently have an overall wall-clock timeout for the entire job, separate from and often much stricter in aggregate than the sum of individual per-step timeouts an agent budgets for. An agent that allocates time per step, confirming each step completes within its own limit, can still have the whole job killed by the orchestrator's total-job timeout if the sum of otherwise-successful steps exceeds it — a failure the agent's step-by-step success tracking gives it no warning of until the job is terminated mid-flight, discarding whatever aggregate work was in progress at that moment.
Frequency:Occasional
In a multi-workspace or multi-project system (e.g., separate Slack-style workspaces, Notion-style team spaces, or per-project environments within a single customer account), an agent operating in the context of one workspace is able to access or modify data belonging to a different workspace. Unlike a multi-tenant/account failure, this typically happens within a single customer's account across their own workspaces, and is usually rooted in shared backend infrastructure — a single search index, vector store, or cache — that wasn't partitioned by workspace ID as strictly as the application layer assumes.