AI Agents Are Exceeding Permissions at Scale. Here Are the Queries Your SIEM Is Missing.

Scan your internal subnets for ports 7860, 3000, and 5678. If you find anything listening on these ports, you may have unmanaged AI infrastructure worth investigating immediately. When I audited agent infrastructure at a large enterprise, we discovered unauthorized AI builder instances holding production database credentials that no one on the security team knew existed.

A Cloud Security Alliance survey released April 21 found that 82% of enterprises have unknown AI agents running in their infrastructure. Two earlier CSA surveys established the surrounding picture: 53% of organizations have had AI agents exceed their intended permissions, and 68% cannot distinguish between AI agent and human activity. A separate Gravitee report of 900+ practitioners found that 82% of executives believe their existing policies cover agent behavior, while only 14.4% of organizations report all AI agents going live with full security and IT approval.

As AI tooling becomes more autonomous, the time between scope drift and actual damage reduces. Detection logic needs to be implemented in the control plane, not in quarterly reviews. The necessary data is in your SIEM, your Kubernetes audit logs, and your cloud provider audit logs, just not configured to search for agent-specific behaviors. Here is what to build, using infrastructure you already operate, organized in three detection layers: network discovery, API audit analysis, and credential usage monitoring.

Layer 1: Network-Level Agent Discovery

The first detection layer answers the question: "Do we have AI agent infrastructure we don't know about?" The CSA/Zenity survey found that agent deployment is decentralized across IT, security, engineering, and customer-facing functions. Shadow AI isn't a theoretical risk. It is already operational.

AI builder tools run on known default ports. Network scans will quickly reveal unmanaged agent infrastructure.

Shadow AI Default Ports Quick Reference

# Locate instances of shadow AI builders on a single network segment.
# Port 3000 (dev server) and 8080 (proxy) will produce false
# positives; heuristics on default ports alone are not an
# exhaustive inventory.

AGENT_PORTS="7860,3000,5678,8080,2718"

# Replace 10.0.0.0/16 with a segment from your asset inventory.
# Repeat for each approved RFC1918 segment rather than sweeping
# all private ranges in one scan.

nmap -sS -p $AGENT_PORTS 10.0.0.0/16 \
  --open -oG agent-scan-results.txt

grep "open" agent-scan-results.txt | \
  awk '{print $2, $NF}' | \
  sort -u > shadow-agents-found.txt

echo "Shadow AI endpoints found:"
cat shadow-agents-found.txt

# Example output (a finding):
# 10.0.4.23 7860/open/tcp//unknown///
# 10.0.12.7 3000/open/tcp//ppp///
# 10.0.12.7 5678/open/tcp//rrac///
# Cross-reference each hit against your approved AI tool inventory.
# Port 3000 hits need manual verification (could be any Node app).
# Port 7860 and 5678 hits are high-confidence AI builder indicators.

For Kubernetes environments, query for pods running known AI builder images. This catches deployments on non-default ports too:

# Find AI builder workloads across all namespaces.
# This is more reliable than port scanning for K8s environments
# because it matches container images regardless of port config.

kubectl get pods --all-namespaces -o json | \
  jq -r '.items[] |
    select(.spec.containers[].image |
       test("langflow|flowise|n8n|dify|openwebui|marimo")) |
     "\(.metadata.namespace)/\(.metadata.name) \(.spec.containers[].image)"'

# Sample finding:
# dev-tools/langflow-7b4d9f8-x2k4p   langflowai/langflow:1.2.0
# ml-sandbox/flowise-deploy-abc12    flowiseai/flowise:2.1.0
# If this namespace is missing from your approved AI tool inventory,
# escalate straight away. Also look for bespoke tool embedded images;
# the image name regex may require extending.

Any result from either query that is not in your approved AI tool inventory is an unmanaged attack surface holding credentials you are not monitoring.

Layer 2: API Audit Log Analysis

The second detection layer addresses the question, "Are our known agents going beyond their intended scope?" This involves processing your existing API audit logs to identify behavioral patterns that differentiate agent behavior from human behavior.

Agent Scope Violation Detection Matrix

For Docker environments in particular, look for the oversized-request pattern in the daemon logs that CVE-2026-34040 exploits:

# Possible AuthZ plugin bypass requests with large payloads.
# Check the Docker daemon logs.
# NOTE: the log format differs by Docker version and logging driver.
# This example handles the default journald format. If you use
# json-file or fluentd, you will need to adjust parsing to fit
# your case.

journalctl -u docker --since "7 days ago" -o json | \
  jq -r 'select(.MESSAGE | test("content.length|ContentLength")) |
    select((.MESSAGE | capture("(?<size>[0-9]+)").size | tonumber) > 1048576) |
    "\(.__REALTIME_TIMESTAMP) \(.MESSAGE)"'

# Expected result (no findings):
# (blank)
#
# Sample result (a finding):
# 1713400000000000 ContentLength: 1153434 ...
# This pattern is similar to the CVE-2026-34040 AuthZ bypass.
# Act quickly: confirm the version of the Docker Engine (patch to 29.3.1)
# and determine if the request was sent to a privileged endpoint.

For Kubernetes API server audit logs, look for agent service accounts that are making requests outside their anticipated namespace or resource scope:

# Looking for agent service accounts for anomaly detection.
# NOTE: This presumes there is an organizational naming convention
# for agents. If your organization implements labeling instead, you
# can query by label (i.e., app.kubernetes.io/component=ai-agent) or
# by ServiceAccount metadata annotations.
# Finding logs based on user-initiated actions that match given
# Agent, AI, LLM, or Bot prefixes, and have a 2xx response status.

cat /var/log/kubernetes/audit.log | \
    jq -r 'select(.user.username | test("agent|ai-|llm-|bot-")) |
    select(.responseStatus.code >= 200 and .responseStatus.code < 300) |
    "\(.requestReceivedTimestamp) \(.user.username) \(.verb) \(.objectRef.resource)/\(.objectRef.namespace)"' | \
    sort |
    uniq -c | sort -rn | head -20

# Sample output (a finding):
# 47 2026-04-15T03:22:11Z  ai-coding-bot  get secrets/production
# 23 2026-04-15T03:22:14Z  ai-coding-bot  list pods/kube-system
# 12 2026-04-15T03:22:18Z  ai-coding-bot  get configmaps/monitoring
# An agent service account accessing secrets in production
# or listing pods in kube-system is a scope violation.
# False positive check: is this SA supposed to have cross-namespace
# access? If yes, tighten its RBAC. If no, investigate.

Layer 3: Credential Usage Monitoring

The third detection layer answers: "Are credentials held by AI tool hosts being used from unexpected sources?" If AI builder tools such as Flowise (CVE-2025-59528, CVSS 10.0), Langflow, or n8n are compromised, the attacker gets all of the tool's stored credentials: API keys for frontier models, database credentials, vector store tokens, and OAuth tokens for business systems.

In the IETF document draft-klrc-aiagent-auth-01 (March 2026), the authors from Defakto Security, AWS, Zscaler, Ping Identity, and OpenAI suggest using dynamically created, short-lived tokens instead of static credentials. Another IETF submission, the Agent Identity Protocol draft (draft-prakash-aip-00), states that in a survey of about 2,000 MCP servers, none were found to use authentication. Where short-lived tokens are not yet supported (most AI builder tools do not support SPIFFE or WIMSE natively), compensating controls are essential.

For each AI builder host, monitor whether its stored credentials are used from any source other than the host itself:

# Monitor AWS CloudTrail for API keys used from unexpected IPs.
# Replace with your AI builder host's known IP and access key.
# For GCP, use Cloud Audit Logs; for Azure, use Activity Log.

BUILDER_HOST_IP="10.0.1.50"
ACCESS_KEY="AKIA..."  # The key stored in your AI builder

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=$ACCESS_KEY \
  --start-time $(date -d '7 days ago' -u +%Y-%m-%dT%H:%M:%SZ) \
  --query 'Events[?sourceIPAddress!=`'$BUILDER_HOST_IP'`].{Time:EventTime,IP:sourceIPAddress,Event:EventName}' \
  --output table

# Clean result (no findings):
# (empty table)
# Sample result (a finding):
# | 2026-04-14T08:12:33Z | 198.51.100.42 | GetObject      |
# | 2026-04-14T08:12:35Z | 198.51.100.42 | ListBuckets    |
# This indicates the credential is being used from an IP
# that is not your AI builder host. Investigate immediately.
# Check if the IP belongs to another internal service (benign
# credential sharing) or an external address (likely compromise).

Beyond Static Thresholds: Behavioral Baselines

Static thresholds are a starting point, not a destination. A data pipeline agent that legitimately handles large payloads will trigger the 1 MB alert every day, and your team will learn to ignore it. The next step is per-agent behavioral baselines that track each agent identity's normal pattern: target service set, request-size distribution (50th, 95th, and 99th percentiles), active hours, request frequency, and retry profile. Replace the static rule with a deviation rule against the agent's 30-day baseline:

IF agent_identity = "ai-coding-bot"
AND target_service NOT IN [baseline_service_set]
AND time_since_last_baseline_update < 7d
THEN alert: "Agent contacting service outside established baseline"
    severity: HIGH

Static thresholds get you detection today. Behavioral baselines get you detection that scales without alert fatigue.

What to Build This Sprint

1. Run the network discovery scan today. Nmap and kubectl queries take several minutes. Refer to the Shadow AI Default Ports table. Each unauthorized AI builder instance is an unmanaged credential store with an attack surface that you are not monitoring. Remediate or register every instance found.

2. Insert agent-behavioral detection rules into your SIEM. Using the detection matrix above, set up alerts for oversized requests (> 1 MB), burst-rate operations (> 100 req/min from a single identity), and cross-service lateral movement (a single identity hitting 3+ services in under 60 seconds). After the first week, adjust the thresholds based on your environment. Some agents send large payloads. The goal is for the rule to be a baseline you refine, not one you learn to ignore. Fluent Bit or the OTel Collector can move audit logs from Kubernetes and Docker to your SIEM or to Loki/Elastic for analysis. For detection at runtime of unexpected process behavior within agent containers, Falco rules can complement the audit log approach.

3. Tag agent identities in your IAM system. If your agent service accounts are similar in structure and representation to human service accounts, you will be unable to pinpoint scope violations. Apply a consistent naming convention or metadata tag (e.g., prefix ai- or label identity-type: agent) to all agent identities so your audit log queries can filter for agent-specific activity. Where naming policies are impractical, Kubernetes annotations or cloud provider resource tags may serve as the differentiating metadata. The K8s audit log query above relies on this.

4. Credential audits per AI builder host. For every instance of Langflow, Flowise, n8n, or any custom AI pipeline, document every credential. Classify each credential by lifespan (static key vs. short-lived token). Then query your cloud provider's audit logs for usage from unexpected sources. Lastly, begin migrating static keys to short-lived tokens where the downstream service supports it.

5. Establish agent-specific detection SLAs. Based on results from the CSA/Zenity survey, 58% of organizations take five or more hours to uncover agent incidents. For autonomous systems operating at machine speed, a five-hour detection window is not a detection window. It is a free pass. Detection thresholds for agent scope violations should be set to minutes, instead of hours. If your SIEM can alert on failed login attempts in real time, it can alert on agent scope violations in real time. The data is already in your logs. You are just not querying for the right patterns.

The detection gap for AI agent scope violations isn't a tooling problem. The data is available through your SIEM, your Kubernetes audit logs, and the audit trails from your cloud provider. The gap is that nobody configured them to look for agent-specific behavioral patterns because, until recently, there were no agents to look for. 

That situation has now changed. The queries in this article will take you less than one hour to complete. Initiate the nmap scan first. If you find a Langflow instance on port 7860 that nobody on your team authorized, you will have your answer as to whether agent scope violations are a theoretical concern or a present one.