{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "What is agent identity spoofing?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Agent identity spoofing is when an attacker impersonates a legitimate AI agent during an agentic transaction by stealing or forging the agent's authentication credentials, certificates, or signed requests. The spoofed agent then issues purchases, transfers, or API calls that the payment system processes as if they came from the trusted agent. Detection works by profiling each agent's normal IP, ASN, certificate fingerprint, user agent, and signing cadence, then alerting when an authenticated request deviates from that baseline."
}
},
{
"@type": "Question",
"name": "How do attackers spoof an AI agent's identity?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Attackers spoof an AI agent's identity through four common paths: stealing the agent's API key or OAuth token from a compromised host, replaying a captured signed request before its nonce expires, generating a forged client certificate with a copied subject when the verifier does not pin the fingerprint, or impersonating the agent over MCP by registering a lookalike server name. Once any of these paths succeeds, the attacker drives transactions under the agent's authenticated identity until the abuse is detected."
}
},
{
"@type": "Question",
"name": "What signals indicate identity spoofing?",
"acceptedAnswer": {
"@type": "Answer",
"text": "The strongest signals are a new autonomous system number (ASN) for an agent that has historically called from one or two cloud ASNs, a previously unseen TLS client certificate fingerprint, a different user agent string, an unfamiliar signing key ID, and request shape drift such as different header ordering, missing optional fields, or off-cadence timing. Any single signal can be a benign change. Two or more appearing together within minutes is high confidence spoofing."
}
},
{
"@type": "Question",
"name": "How does streaming SQL detect identity anomalies?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Streaming SQL detects identity anomalies by maintaining a per-agent baseline materialized view that tracks distinct ASNs, certificate fingerprints, and user agents. A second materialized view joins each new authentication event against the baseline and flags attributes never seen before for that agent. RisingWave keeps both views continuously updated as Kafka events arrive, so an anomalous auth surfaces within sub-second latency without any batch job or feature store."
}
}
]
}
Agentic transactions move money. A shopping agent buys groceries on behalf of its user, a booking agent reserves a flight, a payment agent transfers funds between accounts. Every one of these actions is gated by the agent authenticating itself to a payment API: an API key in a header, a TLS client certificate at the connection, an HTTP message signature over the request body. If an attacker steals or forges any of those credentials, the payment system processes spoofed transactions as if they came from the trusted agent.
Agent identity spoofing is not theoretical. It is the natural extension of API key theft and OAuth token replay into a world where the principal making the call is an autonomous program rather than a human. Worse, the agent's authenticated traffic looks legitimate by design. There is no failed login burst, no impossible-travel signature, no captcha to break. The credentials are valid; the question is whether the entity holding them is the original agent or someone who copied them.
This post shows how to detect agent identity spoofing in real time using RisingWave, an open-source PostgreSQL-compatible streaming database. We profile each agent's behavioral fingerprint with materialized views, score every new authentication against that fingerprint, and surface novel-attribute combinations within seconds. All in plain SQL.
How AI Agents Authenticate to Payment Systems
Before detecting spoofed identity, it helps to be precise about what an agent's identity actually is. In production agentic stacks today, an agent typically authenticates through one of four mechanisms.
API keys and OAuth tokens. The simplest pattern. The agent ships with a secret it presents in an Authorization header. The payment system looks the secret up, resolves it to an agent record, and processes the request. Everything depends on the secret staying secret. Once exfiltrated, it is indistinguishable from the original.
Mutual TLS with client certificates. The agent presents a certificate at the TLS handshake, signed by an authority the payment system trusts. The fingerprint of that certificate (SHA-256 of the DER-encoded body) uniquely identifies the agent. Pinning the fingerprint server-side, rather than just validating the chain, defeats forged-but-trusted-CA attacks.
HTTP message signatures (RFC 9421). The agent signs the request body and a covered set of headers with a private key. The payment system verifies the signature using a public key bound to the agent's keyId. A captured signature can be replayed within the validity window unless a nonce is enforced.
Model Context Protocol (MCP) and agent-to-agent handshakes. When an agent talks to another agent (a payment service exposed as an MCP server, for example), identity flows over the MCP transport. A registered server name plus a session token plus an underlying transport identity (TLS or signed JWT) form the composite identity.
In practice, large deployments combine layers. A payment agent might authenticate over mTLS, then sign each individual request, then carry an OAuth bearer for the user it is acting on behalf of. Each layer is a separate spoofing surface.
Common Agent Identity Attacks
Four attack patterns dominate the agent identity threat model. Detection logic differs slightly for each, but all of them produce the same observable: an authenticated request that looks subtly unlike the agent's history.
Credential theft. The attacker exfiltrates an API key from a compromised host, a leaked environment variable in a Docker image, a misconfigured secrets bucket, or a screen-recording of a developer's terminal. The stolen credential then gets called from a totally different network. Cloud-resident agents authenticate from AWS, Google Cloud, or Azure ASNs; stolen keys frequently surface from residential ISPs, anonymizing VPN ranges, or hosting providers used by automation panels.
Signature replay. When HTTP message signatures are used without nonce enforcement, a network observer (or anyone with access to a request log) can replay the captured signed request. The signature is valid. The attacker did not need the private key. The replay typically arrives from a different ASN or with shifted timing relative to the agent's normal cadence.
Certificate spoofing. The attacker either compromises a CA the verifier trusts, or exploits a verifier that only checks chain validity rather than the specific fingerprint. A new certificate with the agent's subject name passes validation but its fingerprint does not match what the agent has used historically.
MCP impersonation. In an MCP-based architecture, an attacker registers a server with a name confusingly similar to a trusted server, or compromises the registry and substitutes an endpoint URL. Downstream agents connect to the impostor and forward credentials or sensitive data.
A fifth pattern worth calling out is internal compromise. Most identity spoofing detection literature assumes the attacker is external. In practice, a disgruntled engineer with access to the production secrets vault can extract an agent's signing key and run it from their own laptop. The signature verifies. The chain of trust holds. Only the behavioral envelope (ASN, cert, request shape) reveals the substitution. A detection pipeline that treats internal-origin requests as automatically trusted misses this case entirely.
For more detail on the broader attack surface in agent systems, the OWASP Top 10 for LLM Applications catalogs related categories including LLM02 Insecure Output Handling and LLM06 Sensitive Information Disclosure that interact with the spoofing problem.
Behavioral Identity Signals
The detection problem reduces to: given a stream of authenticated requests, score how confident we are that the entity behind each request matches the agent it claims to be. We do this by tracking signals that an attacker cannot trivially copy along with the credential.
IP address and ASN. The single most useful signal. A given agent runs on a specific cloud, in a specific region. Its source IPs cluster within a small set of ASNs. A request authenticating as agent_alpha from AS14618 (AWS) for the past 90 days that suddenly arrives from AS4224 (a residential ISP) is a credential the attacker is using from their own laptop. Even sophisticated attackers who route through cloud VPCs to mask the origin tend to land in different ASNs than the original agent.
TLS certificate fingerprint. When mTLS is configured with fingerprint pinning, this is a hard signal. A novel fingerprint for an agent that has presented exactly one fingerprint for its lifetime is either a key rotation event (which should arrive through your change management pipeline) or spoofing.
Signing key ID and cadence. Agents sign requests at a measurable rate, with predictable inter-request intervals when batching. A spoofer using a captured signature operates on different cadence: bursts followed by silence, or off-hours activity for an agent that normally runs during business hours.
User agent and request shape. The user agent string carried by the agent's HTTP client is a behavioral fingerprint. So is the order of headers, the presence of optional fields, the JSON serialization style (sorted keys vs insertion order), and content lengths. Most attackers reproduce the user agent string but not the full request shape.
The art of identity scoring is combining these so that no single false positive (a legitimate cert rotation, a new region rollout) generates alerts on its own, but two or three together do.
A useful mental model is to treat each identity attribute as a noisy bit. ASN match is one bit, cert fingerprint match is another, user agent match is a third, signing cadence within tolerance is a fourth. Any single bit being off is normal background noise. Two off raises the priority. Three off is a near-certain spoof. The streaming layer's job is to keep all four bits computable in O(1) for every incoming request, which is exactly what materialized views provide.
The signals that DO NOT work in isolation are also worth naming. Geolocation derived from IP is unreliable because cloud regions span continents and IP geolocation databases lag by weeks. Time-of-day patterns are weak because globally deployed agents serve users across time zones. Request volume is weak because legitimate traffic spikes (Black Friday for shopping agents, end-of-quarter for finance agents) look identical to credential abuse on rate alone. The signals listed above are the ones that empirically separate signal from noise.
Building Identity Profiles With Streaming SQL
We need two things from the streaming layer: a per-agent baseline that captures the set of attributes seen historically, and an anomaly view that compares each new authentication against that baseline. Both have to update continuously because agent fleets change and attackers move fast.
Start with the source table. In production this would be a Kafka source ingesting auth events; for the demo we use a base table so you can replay it locally.
CREATE TABLE aap11_agent_auth (
auth_id VARCHAR PRIMARY KEY,
agent_id VARCHAR,
user_id VARCHAR,
ip_address VARCHAR,
asn INT,
cert_fingerprint VARCHAR,
user_agent VARCHAR,
auth_time TIMESTAMPTZ
);
Now seed the table with five agents that have established identity profiles, plus two spoofing attempts at the end. Agent agent_alpha is a shopping assistant that always authenticates from AWS (AS14618) with cert fp_alpha_01. Agent agent_gamma is a payment helper that authenticates from Google Cloud (AS15169) with cert fp_gamma_22.
INSERT INTO aap11_agent_auth VALUES
-- Agent A (shopping): AWS ASN, fp_alpha_01, SmartShopper UA
('a1','agent_alpha','user_001','52.1.10.5', 14618,'fp_alpha_01','SmartShopper/1.4','2026-05-06 09:00:00+00'),
('a2','agent_alpha','user_001','52.1.10.6', 14618,'fp_alpha_01','SmartShopper/1.4','2026-05-06 09:30:00+00'),
('a3','agent_alpha','user_002','52.1.10.7', 14618,'fp_alpha_01','SmartShopper/1.4','2026-05-06 10:00:00+00'),
('a4','agent_alpha','user_003','52.1.10.8', 14618,'fp_alpha_01','SmartShopper/1.4','2026-05-06 10:30:00+00'),
-- Agent B (booking): AWS ASN, fp_beta_07
('b1','agent_beta', 'user_010','3.220.5.1', 16509,'fp_beta_07','BookingBot/2.1','2026-05-06 09:05:00+00'),
('b2','agent_beta', 'user_010','3.220.5.2', 16509,'fp_beta_07','BookingBot/2.1','2026-05-06 09:35:00+00'),
('b3','agent_beta', 'user_011','3.220.5.3', 16509,'fp_beta_07','BookingBot/2.1','2026-05-06 10:05:00+00'),
-- Agent C (payment): Google Cloud ASN, fp_gamma_22
('c1','agent_gamma','user_020','35.190.1.1', 15169,'fp_gamma_22','PayHelper/3.0','2026-05-06 09:10:00+00'),
('c2','agent_gamma','user_020','35.190.1.2', 15169,'fp_gamma_22','PayHelper/3.0','2026-05-06 09:40:00+00'),
('c3','agent_gamma','user_021','35.190.1.3', 15169,'fp_gamma_22','PayHelper/3.0','2026-05-06 10:10:00+00'),
-- Agent D (travel): Azure ASN, fp_delta_31
('d1','agent_delta','user_030','40.112.7.1', 8075,'fp_delta_31','TravelMate/1.0','2026-05-06 09:15:00+00'),
('d2','agent_delta','user_030','40.112.7.2', 8075,'fp_delta_31','TravelMate/1.0','2026-05-06 09:45:00+00'),
('d3','agent_delta','user_031','40.112.7.3', 8075,'fp_delta_31','TravelMate/1.0','2026-05-06 10:15:00+00'),
-- Agent E (grocery): Cloudflare ASN, fp_epsilon_55
('e1','agent_epsilon','user_040','104.21.5.1',13335,'fp_epsilon_55','GroceryGopher/2.5','2026-05-06 09:20:00+00'),
('e2','agent_epsilon','user_040','104.21.5.2',13335,'fp_epsilon_55','GroceryGopher/2.5','2026-05-06 09:50:00+00'),
('e3','agent_epsilon','user_041','104.21.5.3',13335,'fp_epsilon_55','GroceryGopher/2.5','2026-05-06 10:20:00+00'),
-- SPOOFING ATTEMPT 1: agent_alpha from a residential ISP ASN with stolen-key-substitute cert
('s1','agent_alpha','user_001','185.220.101.45', 4224, 'fp_stolen_99','SmartShopper/1.4','2026-05-06 11:00:00+00'),
-- SPOOFING ATTEMPT 2: agent_gamma from a different ASN with replayed-signature curl client
('s2','agent_gamma','user_020','91.219.236.50', 9009, 'fp_replay_77','curl/8.1.2', '2026-05-06 11:05:00+00');
Now the per-agent baseline view. It computes the cardinality of distinct identity attributes for each agent, plus the time window over which the agent has been observed.
CREATE MATERIALIZED VIEW aap11_agent_identity_baseline_mv AS
SELECT
agent_id,
COUNT(*) AS total_auths,
COUNT(DISTINCT asn) AS distinct_asns,
COUNT(DISTINCT cert_fingerprint) AS distinct_certs,
COUNT(DISTINCT user_agent) AS distinct_user_agents,
COUNT(DISTINCT ip_address) AS distinct_ips,
MIN(auth_time) AS first_seen,
MAX(auth_time) AS last_seen
FROM aap11_agent_auth
GROUP BY agent_id;
Querying that view returns the identity envelope for every agent we know about:
agent_id | total_auths | distinct_asns | distinct_certs | distinct_user_agents | distinct_ips | first_seen | last_seen
---------------+-------------+---------------+----------------+----------------------+--------------+---------------------------+---------------------------
agent_alpha | 5 | 2 | 2 | 1 | 5 | 2026-05-06 09:00:00+00:00 | 2026-05-06 11:00:00+00:00
agent_beta | 3 | 1 | 1 | 1 | 3 | 2026-05-06 09:05:00+00:00 | 2026-05-06 10:05:00+00:00
agent_delta | 3 | 1 | 1 | 1 | 3 | 2026-05-06 09:15:00+00:00 | 2026-05-06 10:15:00+00:00
agent_epsilon | 3 | 1 | 1 | 1 | 3 | 2026-05-06 09:20:00+00:00 | 2026-05-06 10:20:00+00:00
agent_gamma | 4 | 2 | 2 | 2 | 4 | 2026-05-06 09:10:00+00:00 | 2026-05-06 11:05:00+00:00
Notice that agent_alpha and agent_gamma already show 2 distinct ASNs and 2 distinct certs in their baseline. That elevation is exactly the spoofing attempts being absorbed into the baseline. In production you would gate baseline updates so that suspect events are excluded until they are confirmed legitimate, but for this demo we are showing the raw cardinality.
A second view captures recent activity. This is the working window over which downstream alerting logic will run.
CREATE MATERIALIZED VIEW aap11_recent_auth_mv AS
SELECT
auth_id,
agent_id,
user_id,
ip_address,
asn,
cert_fingerprint,
user_agent,
auth_time
FROM aap11_agent_auth
WHERE auth_time > NOW() - INTERVAL '7 days';
Aggregating over the recent view gives a quick operational picture of agent traffic over the past week:
agent_id | recent_auths | recent_asns | recent_certs
---------------+--------------+-------------+--------------
agent_alpha | 5 | 2 | 2
agent_beta | 3 | 1 | 1
agent_delta | 3 | 1 | 1
agent_epsilon | 3 | 1 | 1
agent_gamma | 4 | 2 | 2
The anomalous expansion in agent_alpha's and agent_gamma's recent ASN and cert counts is your first indicator without even running per-event detection.
Detecting Identity Anomalies in Real Time
Per-event detection is where streaming SQL earns its keep. For each authentication event, we want to know: have we seen this combination of (agent, ASN), (agent, cert fingerprint), and (agent, user agent) before? If any one is novel and the agent already has prior history, that auth is a spoofing candidate.
We use correlated subqueries to compare each event against the prior authentications of the same agent.
CREATE MATERIALIZED VIEW aap11_identity_anomalies_mv AS
SELECT
a.auth_id,
a.agent_id,
a.user_id,
a.ip_address,
a.asn,
a.cert_fingerprint,
a.user_agent,
a.auth_time,
NOT EXISTS (
SELECT 1 FROM aap11_agent_auth p
WHERE p.agent_id = a.agent_id
AND p.asn = a.asn
AND p.auth_time < a.auth_time
) AS new_asn_for_agent,
NOT EXISTS (
SELECT 1 FROM aap11_agent_auth p
WHERE p.agent_id = a.agent_id
AND p.cert_fingerprint = a.cert_fingerprint
AND p.auth_time < a.auth_time
) AS new_cert_for_agent,
NOT EXISTS (
SELECT 1 FROM aap11_agent_auth p
WHERE p.agent_id = a.agent_id
AND p.user_agent = a.user_agent
AND p.auth_time < a.auth_time
) AS new_ua_for_agent,
(SELECT COUNT(*) FROM aap11_agent_auth p
WHERE p.agent_id = a.agent_id
AND p.auth_time < a.auth_time) AS prior_auth_count
FROM aap11_agent_auth a;
The prior_auth_count field gates the anomaly detection so we do not flag every agent's very first authentication as suspicious. We require at least two prior auths before novelty is treated as actionable.
Querying for real anomalies returns exactly the two spoofing attempts:
SELECT auth_id, agent_id, user_id, ip_address, asn, cert_fingerprint, user_agent,
new_asn_for_agent, new_cert_for_agent, new_ua_for_agent, prior_auth_count
FROM aap11_identity_anomalies_mv
WHERE prior_auth_count >= 2
AND (new_asn_for_agent OR new_cert_for_agent OR new_ua_for_agent)
ORDER BY auth_time;
auth_id | agent_id | user_id | ip_address | asn | cert_fingerprint | user_agent | new_asn_for_agent | new_cert_for_agent | new_ua_for_agent | prior_auth_count
---------+-------------+----------+----------------+------+------------------+------------------+-------------------+--------------------+------------------+------------------
s1 | agent_alpha | user_001 | 185.220.101.45 | 4224 | fp_stolen_99 | SmartShopper/1.4 | t | t | f | 4
s2 | agent_gamma | user_020 | 91.219.236.50 | 9009 | fp_replay_77 | curl/8.1.2 | t | t | t | 3
Both spoofs surface cleanly. s1 (the credential theft) flips new_asn_for_agent and new_cert_for_agent because the attacker has the API credential but is calling from their own infrastructure with a fresh cert. The user agent header was preserved by the attacker, which is typical: the easiest header to copy is the one already in the leaked sample request. s2 (the signature replay attempt with a curl client) flips all three flags because the attacker did not bother to mimic the legitimate agent's user agent string.
The view updates incrementally as new authentications arrive. RisingWave maintains the correlated subquery state in its shared storage layer on S3-compatible object storage, so the join cost is amortized rather than re-scanned each query.
Composing Signals Into an Identity Trust Score
Boolean flags are useful, but production systems usually want a single number. A trust score per authentication, between 0 and 100, lets the payment system route requests to friction tiers: trust above 80 goes through, 50 to 80 triggers a step-up challenge, below 50 blocks and pages the security team.
A weighted composite captures that the cert fingerprint matters more than the user agent, and the ASN matters about as much as the cert.
SELECT
a.auth_id,
a.agent_id,
a.user_id,
a.ip_address,
a.asn,
100
- CASE WHEN a.new_asn_for_agent THEN 35 ELSE 0 END
- CASE WHEN a.new_cert_for_agent THEN 40 ELSE 0 END
- CASE WHEN a.new_ua_for_agent THEN 25 ELSE 0 END AS trust_score
FROM aap11_identity_anomalies_mv a
WHERE a.prior_auth_count >= 2
ORDER BY trust_score ASC, a.auth_time DESC
LIMIT 5;
auth_id | agent_id | user_id | ip_address | asn | trust_score
---------+---------------+----------+----------------+-------+-------------
s2 | agent_gamma | user_020 | 91.219.236.50 | 9009 | 0
s1 | agent_alpha | user_001 | 185.220.101.45 | 4224 | 25
a4 | agent_alpha | user_003 | 52.1.10.8 | 14618 | 100
e3 | agent_epsilon | user_041 | 104.21.5.3 | 13335 | 100
d3 | agent_delta | user_031 | 40.112.7.3 | 8075 | 100
s2 scores 0 because every attribute is novel: new ASN (35), new cert (40), new UA (25). s1 scores 25 because the attacker copied the user agent. Both are well below the friction threshold and would be blocked or challenged. The legitimate auths score 100.
In production the score function should also incorporate request shape signals (header order, body schema), signing cadence (inter-request interval z-score against the agent's historical distribution), and the user the agent claims to act on behalf of. Those are additional materialized views joined into the trust score expression.
A few production-grade refinements are worth noting. First, weight the score with smoothing so that a single novel attribute against a long history does not collapse the score to zero. Bayesian updating against a prior built from the agent's distinct cardinality counts is one approach. Second, decay the baseline so that an agent that legitimately rotated its cert six months ago does not anchor scoring forever. A sliding window or exponentially-weighted view over the last 30 days strikes the right balance. Third, flag and review the very first authentication of every newly registered agent rather than letting the bootstrap event pass unscored. New-agent enrollment is a known abuse vector where attackers register agent identities they control and then begin to issue transactions.
For mature deployments, the score itself should feed back into the baseline. Authentications scoring above some threshold contribute to the baseline; authentications scoring below the threshold are excluded. This breaks the feedback loop where a successful spoof would otherwise teach the system that the attacker's ASN is normal. Implementing it requires gating the baseline materialized view on the trust score view, which RisingWave handles natively because materialized views can reference each other.
You can wire the trust score into a Kafka topic for downstream consumers using a CREATE SINK statement. Many of the same patterns appear in our account takeover detection guide, and the agent fraud detection landing page covers the full set of agentic-commerce defenses.
If you are bridging to enterprise agent platforms, the Anthropic Claude Agent SDK documentation describes the per-request identity that needs to be carried into the auth event stream so detection has the right primary key.
FAQ
What is agent identity spoofing? An attacker presents an AI agent's stolen, forged, or replayed authentication material to a payment system, causing the system to process the attacker's transactions as though they originated from the trusted agent.
How do attackers spoof an AI agent's identity? Four common paths: stealing API keys or OAuth tokens from compromised hosts, replaying captured signed requests within the validity window, presenting forged client certificates when the verifier does not pin the fingerprint, and impersonating an agent's MCP endpoint with a lookalike server registration.
What signals indicate identity spoofing? Novel ASN for an agent that historically resided in one or two cloud ASNs, novel TLS fingerprint, novel user agent, novel signing key ID, request shape drift such as different header ordering or missing optional fields, and off-cadence timing relative to the agent's normal request rhythm.
How does streaming SQL detect identity anomalies? A per-agent baseline materialized view tracks distinct ASNs, certs, and user agents. A correlated subquery against the auth stream flags new combinations as they arrive. RisingWave updates both views incrementally, so anomalies surface within sub-second latency without batch ETL or a separate feature store.
Conclusion
Agent identity is the new perimeter for agentic transactions. As autonomous agents take over more of the purchasing, booking, and transferring that humans used to do by hand, the credentials those agents carry become high-value targets. Static authentication alone (validate the signature, accept the request) cannot tell whether the entity behind the credential is the original agent or an attacker who copied it. You need behavioral identity scoring, computed continuously, joined per-event against a baseline that updates in real time.
Streaming SQL is the right primitive for this. The detection logic is set arithmetic over event streams: which ASNs has this agent used before, which certs, which user agents. RisingWave's PostgreSQL-compatible streaming engine maintains those sets as materialized views, joins them against incoming auths with correlated subqueries, and serves trust scores over a normal SQL connection. No Java, no separate feature store, no batch retraining cadence. The model is the materialized view.
Ready to detect agent identity spoofing in real time? Try RisingWave Cloud free.
Join our Slack community to compare notes with other teams building agentic transaction defenses on streaming SQL.
