An AI agent that reads 4,000 customer records to answer a question about one customer is over collecting, even when every read was allowed by its permissions. Permission checks answer "may this agent read this?" and never "did this task need it?", so over collection passes through access control untouched and only shows up if you measure it. This guide treats data volume per task as a detection signal: how to define what a task needs, how to count what the agent actually pulled from each source, how to turn the gap into alerts, and how to respond. It is for detection engineers, AI platform teams and data protection leads who already run general behaviour baselines and want a sharper signal for data minimisation. General agent baselining (tool sequences, egress, timing) is covered in the AI Agent Behaviour Baselining and Anomaly Detection Guide; this page goes deep on one dimension only.
Key takeaways
- Measure the gap, not the total. The useful signal is records read divided by records the task needed (the read amplification ratio), per task, not raw daily volume per agent.
- Need comes from the task, not from history. Declare an expected data envelope per task type (sources, scope key, record ceiling) and use learned baselines only to tune it.
- Count at the tool boundary. The tool gateway or MCP server is the only place that sees task ID, tool call and result size together; platform audit logs confirm and fill gaps.
- Scope mismatch beats volume. A task about customer 1182 that touches records for other customers is a stronger alert than any volume threshold, and it catches injected queries early.
- Over collection is also a compliance finding. GDPR Article 5(1)(c) requires data "limited to what is necessary"; per-task read evidence is how you demonstrate it under Article 5(2).
Why over collection is its own detection problem
Agents read data through tools with a fixed identity, and the identity is usually scoped to the whole data set a tool might ever need. A support agent that can look up any customer can therefore list every customer, and nothing in the authorisation path objects. OWASP LLM06:2025 Excessive Agency names the root causes as excessive functionality, excessive permissions and excessive autonomy; over collection is what those causes look like in the data access log when nothing is being changed, only read.
Three sources produce it, and each leaves a different trace:
- Design over collection: the tool returns more than asked (a "get customer" tool that returns the full account with order history and notes), or retrieval is configured with a high top-k. Every task over collects by a similar factor, so the ratio is stable and high.
- Reasoning over collection: the model decides to "be thorough" and lists, searches or paginates beyond what the request needed. The ratio varies by prompt and model version.
- Induced over collection: injected instructions direct the agent to query data unrelated to the task, as in the ForcedLeak research on Salesforce Agentforce, where text planted in a web form led the agent to query other CRM records and send them out. MITRE ATLAS describes the collection step as AML.T0085 Data from AI Services, with sub-techniques for RAG databases (AML.T0085.000) and agent tools (AML.T0085.001).
Over collection matters before any exfiltration happens. Data pulled into a context window can end up in logs, memory, traces, model provider retention and later outputs. See the AI Agent Memory Security Guide and the Generative AI Data Loss Prevention Guide.
Defining what a task needs
Detection needs a reference point. Write a data envelope for each task type the agent performs, owned by the agent's product owner and reviewed with the data owner. A task type is a stable category ("refund request", "account summary", "weekly sales digest"), not each prompt.
| Envelope field | What it records | Example: "summarise one customer's open tickets" |
|---|---|---|
| Sources | Tools and data stores the task may read | Ticketing API, CRM contact lookup |
| Scope key | The entity every record should relate to | customer_id from the request |
| Record ceiling | Maximum records per source per task | 50 tickets, 1 contact |
| Field set | Fields needed; sensitive fields excluded | Ticket title, status, last update; no payment fields |
| Operation types | Lookup by key, search, list, export, bulk read | Lookup and filtered search; no list-all or export |
| Fan-out ceiling | Tool calls and pagination depth per task | 10 tool calls, 3 pages |
| Sensitivity ceiling | Highest data classification allowed | Internal and Confidential; no Restricted |
Where the task type cannot be known in advance (general assistants), fall back to two envelopes: a per-request ceiling for each source and a scope rule that all records relate to the requesting user or the entities named in the request. The ICO's guidance on data minimisation makes the same point for people: identify the minimum you need for the purpose and do not collect "on the off-chance that it might be useful in the future". See the Data Minimisation guide.
Signals that show over collection
Volume alone is noisy. Combine several measurements per task, each computed against its envelope.
| Signal | How to compute | What it catches | Typical false positive |
|---|---|---|---|
| Read amplification ratio | Records returned to the agent / records used in the final answer or action (or / envelope ceiling where usage is not tracked) | Design and reasoning over collection | Legitimate exploratory research tasks |
| Scope mismatch rate | Share of returned records whose key differs from the task's scope key | Induced queries, broken filters | Linked entities (household, parent company) not modelled |
| Ceiling breach | Records per source per task above the envelope ceiling | Runaway pagination, list-all calls | Genuinely large accounts |
| Operation shift | Search, list or export calls where the envelope allows lookups | Agent switching from targeted to bulk reads | New tool version renaming operations |
| Source sprawl | Distinct sources read per task above the envelope | Agent wandering into unrelated stores | Multi-step tasks with optional enrichment |
| Sensitive field pull | Restricted fields or labels returned when the envelope excludes them | Wide default projections, SELECT * | Fields included by an upstream schema change |
| Bytes into context | Tokens or bytes of tool results added to the prompt per task | Large documents and attachments pulled whole | Long legitimate documents |
The ratio and the scope mismatch rate carry most of the weight. A high ratio with zero scope mismatch is usually a design fix (narrow the tool). Any scope mismatch on a task with a clear scope key deserves investigation, because it is the pattern an injected instruction produces.
Where to measure
Count at more than one layer. The tool layer knows the task; the platform layer is harder to bypass.
| Layer | Data available | Reference | Limits |
|---|---|---|---|
| Agent traces (OpenTelemetry GenAI conventions) | execute_tool spans with gen_ai.tool.name, gen_ai.tool.call.id, gen_ai.conversation.id; retrieval spans with gen_ai.retrieval.top_k; invoke_agent spans with gen_ai.agent.id | OpenTelemetry semantic conventions for generative AI (status Development) | Tool arguments and results are Opt-In attributes; record counts and keys, not raw content |
| Tool gateway or MCP server | Task ID, tool, query parameters, result count, result keys, bytes | Your own gateway logging | Only covers tools routed through it |
| AWS | CloudTrail data events: S3 GetObject (AWS::S3::Object), DynamoDB item-level calls, Bedrock knowledge base and agent resources; filter with advanced event selectors on userIdentity.arn | AWS CloudTrail documentation | Data events are off by default and charged; scope selectors to agent roles and sensitive resources |
| Microsoft 365 | MailItemsAccessed with Bind records listing InternetMessageId and OperationCount, aggregated per 2 minutes | Microsoft Purview audit documentation | Sync records cover a whole folder; duplicates filtered within an hour |
| Google Workspace | Drive log events "Item content accessed" (API access on a user's behalf) and "Item search performed", with App ID, API method, Impersonation and "By an agent" fields | Google Workspace Drive log events | Opening files in Drive apps is not logged as content accessed |
| Databases and SaaS APIs | Query logs, rows returned, API call logs per client ID | Platform audit features | Often no task context; join on time and identity |
The join key is what makes the platform logs usable: give each agent its own identity (role session name, client ID, service principal) and propagate a task or trace ID into tool calls where the platform supports it. Without a distinct identity per agent, platform logs show only a shared service account. See the AI Agent Authorisation Guide.
Turning measurements into alerts
Use a declared rule first and a learned threshold second.
- Hard rules from the envelope: alert immediately on scope mismatch above a small tolerance, on any Restricted field pull, and on list-all or export operations the envelope forbids. These need no history.
- Ceiling with headroom: alert when records per source exceed the envelope ceiling by an agreed factor (for example 2x), and log ceiling breaches below that for weekly review.
- Learned ratio threshold: once you have enough tasks per task type, compute the read amplification ratio distribution per agent version and alert above a high percentile, using a robust measure (median and median absolute deviation) so a few large tasks do not inflate the baseline.
- Cumulative budget: sum records per agent per source per hour. Slow over collection, where each task stays under the ceiling but the agent runs many unneeded tasks, appears only in the aggregate.
- Correlate with egress: raise severity when an over collection task is followed by a write or send tool call, an outbound URL or a file creation, the pattern ATLAS describes as AML.T0086 Exfiltration via AI Agent Tool Invocation.
| Condition | Severity | Default response |
|---|---|---|
| Ratio above threshold, no scope mismatch, no egress | Low | Ticket to agent owner to narrow tool or retrieval settings |
| Ceiling breach above 2x on Confidential data | Medium | Review the task trace within one working day |
| Scope mismatch on a scoped task | High | Pause the session; inspect inputs for injected text |
| Over collection followed by outbound write or URL | Critical | Suspend agent identity; start incident response |
Preventive controls that make the signal cleaner
- Narrow tools: replace "query" tools with key-based lookups that require the scope key as a parameter; return only envelope fields. OWASP LLM06 recommends minimising extensions and their functionality.
- Enforce ceilings in the gateway: cap page size, pagination depth and result count per call, so a runaway agent hits a limit rather than an alert.
- On-behalf-of access: where the agent acts for a user, use delegated access so reads are bounded by that user's rights, not the agent's broad identity.
- Retrieval settings: set top-k and similarity thresholds per use case and filter by the user's entitlements before ranking.
- Short context retention: do not persist tool results into long-term memory by default; over collected data then has a shorter life.
Permissions that grow over time widen the room for over collection; track them with the Agent Permission Drift guide.
How to implement
- Inventory read tools per agent: list every tool and data source each production agent can read, with the identity it uses. Start with agents that read personal or Restricted data.
- Write envelopes for the top task types: cover the task types that make up most volume; leave a general fallback envelope for the rest.
- Instrument the tool layer: emit task ID, tool name, result count, result keys (hashed if sensitive) and bytes for every read call. Do not log raw results.
- Enable platform logs for agent identities: turn on CloudTrail data events scoped by selector to agent roles, confirm MailItemsAccessed is present for mailboxes agents touch, and include Drive API events for agent app IDs.
- Run in observe mode: compute signals and log would-be alerts for two to four weeks or a set number of tasks per type. Measure the false positive rate per rule.
- Pilot alerts on one agent: enable hard rules and ceilings for a single agent, route alerts to its owner, and tune envelopes from findings.
- Add enforcement gradually: move ceilings into the gateway as blocking limits. Roll back by switching the gateway rule to log-only, which leaves detection running.
- Review on change: re-baseline the ratio on every model, prompt or tool version, and treat a ratio step change after a release as a regression.
Decision guidance
- Small organisations: skip learned thresholds. Envelope hard rules plus a per-call result cap in the gateway catch most issues with little tuning.
- Large organisations: centralise counting in a shared tool gateway, feed metrics to the SIEM, and give each business unit ownership of its envelopes.
- Usage tracking versus ceilings: measuring which records were used in the answer gives the truest ratio but needs application support; ceilings are cruder but work for any agent. Start with ceilings.
- Block versus alert: block where the envelope is well understood and the data is Restricted; alert where tasks vary and a block would break legitimate work.
Measuring whether it works
- Median read amplification ratio per agent: trending down after tool narrowing; a falling ratio is direct evidence of minimisation.
- Envelope coverage: share of agent tasks matched to a declared envelope (target above 90% for agents with personal data).
- Scope mismatch alerts confirmed: share of high-severity alerts that were real issues, to tune tolerance.
- Time to triage: from over collection alert to owner decision.
- Records read per task for Restricted data: trended per quarter and reported to the data owner.
Framework mapping
| Area | Reference | How over collection detection supports it |
|---|---|---|
| Data minimisation | GDPR Art. 5(1)(c), 5(2); NIST SP 800-53 SA-8(33) Minimization | Per-task evidence that reads were limited to purpose |
| Least privilege | NIST SP 800-53 AC-6; CSF 2.0 PR.AA-05 | Ratio data shows where tool scope exceeds need |
| Logging and monitoring | NIST SP 800-53 AU-12, AU-6, SI-4; CSF 2.0 DE.CM-09, DE.AE-02; ISO/IEC 27001:2022 A.8.15, A.8.16 | Tool-level read records and alerting |
| Data leakage | ISO/IEC 27001:2022 A.8.12 | Early signal before data leaves |
| Adversary behaviour | ATLAS AML.T0085, AML.T0086; ATT&CK T1530 Data from Cloud Storage, T1213 Data from Information Repositories, T1119 Automated Collection, T1114.002 Remote Email Collection | Collection techniques the signals detect when an agent is misused |
| LLM risk | OWASP LLM06:2025 Excessive Agency | Detects excessive functionality and permissions in use |
Common failure patterns
- Shared identities: several agents and a batch job share one service account, so platform logs cannot attribute reads to a task or even an agent.
- Daily volume baselines only: an agent that reads 50 unrelated records per task stays inside its daily norm; the per-task scope check would have caught it.
- Logging the data to detect the data: teams log full tool results to count them, creating a second copy of the over collected data. Log counts and hashed keys.
- Envelopes that never change: a new tool version returns more fields and nobody updates the envelope, so sensitive field alerts are muted as noise.
- Trusting the allowlist: in ForcedLeak the exfiltration went through an allowlisted domain; collection signals inside the task were the earlier chance to catch it. See Investigating Agent-Initiated Data Exfiltration.
- Data events left off: CloudTrail data events are not logged by default, so S3 and DynamoDB reads by agent roles are invisible until someone scopes and enables them.
Practitioner checklist
- Give every production agent its own identity and propagate a task or trace ID into tool calls.
- Write a data envelope (sources, scope key, ceilings, fields, operations) for each major task type.
- Log result count, result keys and bytes for every read tool call, without raw content.
- Alert on scope mismatch and forbidden bulk operations from day one.
- Compute the read amplification ratio per agent version and re-baseline after every release.
- Enable CloudTrail data events, MailItemsAccessed and Drive API events for agent identities.
- Cap page size and result counts in the tool gateway, starting in log-only mode.
- Report median ratio and Restricted records per task to data owners each quarter.
Standards and references
- GDPR: Article 5 Principles relating to processing of personal data
- ICO: Principle (c) Data minimisation
- OWASP: Top 10 for LLM Applications 2025 (LLM06 Excessive Agency)
- MITRE ATLAS: Data from AI Services
- OpenTelemetry: Semantic conventions for generative AI
- AWS: Logging data events with CloudTrail
- Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts
- Google Workspace: Drive log events
Related NHI Mgmt Group resources: AI Agent Behaviour Baselining and Anomaly Detection Guide · Agent Controls and Monitoring Guide · MITRE ATLAS AML.T0086 Exfiltration via AI Agent Tool Invocation · AI Agent Tool and Plugin Security Guide