Agent Identity Validation
Checking that an agent is registered, authorized, and working inside its declared tool scope and rate limits. OWASP T9.
- Measured: 40 of 47 payloads, our own corpus
- Not measured: latency
- Observed, not governed: hosted MCP tool calls
What it is
Agent identity validation is the process of verifying that a request genuinely comes from a known, registered agent and that the agent is authorized to take the action it's attempting. Without it, any process can impersonate any agent.
Each agent in production should have a declared identity: agent ID, authorized tools (allowed_tools list), rate limit (max requests per minute), and other metadata. When an agent attempts to use a tool, the governance system verifies: is this agent registered? Is it attempting to use a tool it's allowed to use? Is it within its rate limit?
Why it matters
This is OWASP Agentic AI Threat T9: Identity Spoofing. Without identity validation, an attacker who gains access to the system could spin up a rogue process that looks like agent-trading-bot and use it to trade unauthorized positions. Or a compromised agent could request expanded tool access.
Identity validation also enables per-agent rate limits and tool scoping. Agent A (compliance checker) can only use read_database and send_email. Agent B (incident responder) can use terminate_process and restart_service. This prevents lateral movement: a compromised agent can't access tools it was never authorized for.
How it works
Before a governed tool call executes, the proxy checks: agent provides an ID → lookup in registry → confirm ID exists → confirm requested tool is in agent's allowed_tools list → confirm rate limit not exceeded. If any check fails, the action is denied.
The agent registry is maintained by your operations team and is queryable by the proxy. It's the source of truth for what each agent is allowed to do.
How Intercis implements it
Intercis maintains an agent registry where you define each agent: ID, human-readable name, allowed_tools (list of tool names), rate_limit_rpm (requests per minute), and tags. When the proxy intercepts a tool call, it validates:
- Agent ID is known (exists in registry)
- Agent is active (not suspended or revoked)
- Requested tool is in agent's allowed_tools list
- Agent has not exceeded its rate limit
If validation fails, the action is denied and logged. The registry is a table: adding an agent, revoking one and changing a tool scope are rows, not a release.
Related terms
What Intercis does not govern
Intercis judges the tool calls that cross the Anthropic and OpenAI API wire. When a hosted MCP server runs a tool for the model, that call has already run by the time the response reaches the proxy, so it is observed, not governed: it writes one observe row and is never judged or blocked. Being in path is also a configuration setting: a process that can change its own base URL can route around the proxy unless network egress control forces the traffic through it.
The T-numbers on this page are from Agentic AI Threats and Mitigations v1.1, published by the OWASP GenAI Security Project and read in April 2026. OWASP revises that document, so check the current edition before you carry a number from here into your own threat model.