Detecting an AI agent enumerating customer IDs through a Postgres MCP server

What agent-driven ID enumeration looks like

Enumeration is a series of tool calls whose parameters walk through customer identifiers, either by incrementing a value or by drawing from a broad, patterned set, rather than retrieving the records a task needs. Each call can be individually valid. The agent often holds working credentials and read access, so there is no authentication failure to alert on.

That is the core difficulty. OWASP's MCP Top 10 lists insufficient authentication and authorization (MCP07) as a risk, and its agentic guidance on overpermissioned connectors (AAI6) describes broad data-access credentials granted at initialization with no re-validation before each retrieval. Under those conditions detection has to rely on behavior, not on denied requests.

A useful analogy comes from OWASP's RAG guidance, which treats systematic variation of query terms as reconnaissance of a corpus. Systematic variation of customer ID parameters across tool calls is the equivalent pattern for a Postgres MCP server. This is an inference from that guidance, not an OWASP statement about Postgres. It also resembles the familiar object-level authorization abuse pattern, where a caller iterates over object identifiers.

Normal agent retrieval is anchored to a task: a small number of IDs, usually connected to the user's request or to each other. Enumeration shows breadth with no task anchor.

Signals to collect at the MCP and Postgres layers

At the MCP layer, capture what forensics will need: which tool was called, with what parameters, for what purpose, and by which agent. In practice that means agent identity, session identifier, the user on whose behalf the agent acts, tool name, full parameters, timestamp, result row count and size, and the policy decision taken. OWASP guidance on tool invocations, user-agent interactions and data-access operations points to the same fields, including the query and result set.

At the Postgres layer, treat the following as practitioner design choices. Give the MCP server a dedicated database role per agent or per tool, so that query logs and pg_stat_statements can be attributed. Carry the agent session identifier into the connection, for example through application_name or a session setting, so a log line can be joined to a tool call. Note that pg_stat_statements normalizes constants. It shows query shape, volume and row counts, but not which IDs were requested, so the ID sequence has to come from MCP parameters or statement logs.

Forward both streams to a SIEM for correlation and anomaly detection, and keep them outside the agent's control. OWASP's AIVSS material describes an agent deleting its own forensic artifacts and having it look like routine maintenance, which is a reason to store telemetry where the agent cannot alter it.

Detection patterns to apply

No standard defines numeric enumeration thresholds. Baseline each tool and agent role against normal behavior, then tune. These patterns are most useful when combined, because any one of them can be produced by legitimate batch work.

• Sequential or incrementing IDs: Within one session, parameter values form runs with a constant step, or cover a contiguous range with few gaps.
• High-cardinality lookups: Distinct customer IDs per session, per tool or per time window far exceed the baseline, especially with one record returned per call.
• Abnormal request rate: Tool-call volume per agent identity rises sharply, or calls arrive at a steady machine cadence unrelated to user interaction.
• Result-set breadth: Cumulative rows or distinct customers returned exceed what the stated task needs, including through list or search tools.
• Novel tool or parameter use: The agent calls a lookup tool it has not used before, or varies a parameter it previously held constant.
• Indirect leakage in output: Summaries, comparisons or inferences in agent responses expose records the user should not see, even when raw rows are restricted.

Preventive controls that make detection easier

Detection is weaker when the agent can reach everything. Provision the Postgres connector with the minimum access the task needs, and evaluate authorization on every request at query time, not once at session start. Both points follow OWASP's AAI6 guidance.

For query shape, the following are practitioner recommendations. Expose narrow, parameterized tools such as a lookup by case reference instead of a free-form SQL tool. Where possible, bind queries to the requesting user's scope, and consider row-level security with role-scoped access so the database refuses rows outside that scope. Cap rows per call and require filters that tie a lookup to the task. These choices shrink the space an agent can walk and make anomalies stand out.

Test the result. OWASP recommends trying to reach other users' records through the agent interface and verifying that responses are restricted. Include indirect cases, since summaries and comparisons can leak what raw access controls block.

Choosing a response action

Once a pattern fires, the response should match confidence and impact. The record each action leaves is as important as the action itself. No standard schema exists, so the fields below are a suggested minimum.

• Allow: Use for in-baseline calls. Record identity, session, parameters, result size and the policy that permitted it, so you can later show what the agent was allowed to do.
• Redact: Use when the call is legitimate but the output carries PII or regulated fields the task does not need. Record which fields were removed and under which policy.
• Rate limit: Use for suspicious volume with unclear intent, keyed to agent or user identity. Record the limit, the observed rate and the calls delayed or rejected.
• Block: Use for clear enumeration or out-of-scope identifiers, and as a circuit breaker on anomalous volume. Record the triggering pattern, the blocked parameters and the session state.
• Escalate for human approval: Use for high-impact or out-of-allowlist actions. Pause the agent, then record the request, the approver and the decision.

Enforcing policy in the execution path

Detection that feeds a SIEM tells you what happened. It does not stop the next fifty calls. OWASP guidance separates the two layers: SIEM-fed anomaly detection, and runtime controls such as circuit breakers and pausing the agent for human verification. Both are needed, and the second must act while the session is live.

Trussed enforces policy in the execution path of MCP tool calls, across individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact, with allow, redact, block, rate limit and escalate for human approval available as responses. Because the decision is made where the call passes, the enforcement itself generates audit-ready evidence of what the agent was permitted to do and what it did. For a regulated enterprise, that evidence is mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

Evidence design still involves a tradeoff. OWASP advises minimizing and redacting prompt and output content before storage, while its agentic guidance also recommends keeping queries and result sets for audit. Decide per tool what must be retained, protect it from the agent, and set retention to match. Trussed's scope is the individual call, so correlating a full sequence of calls into an enumeration finding remains a detection task in your own pipeline.