Verdict API
Let your own API or MCP server call ShieldAgent for a security verdict before executing any tool call — without changing your traffic flow.
Overview
The Verdict API is for customers who own and operate their own API or MCP server. Instead of routing agent traffic through the ShieldAgent proxy, your server calls POST /tenants/:tenantId/scan with the incoming request payload. ShieldAgent runs the full multi-stage security pipeline and returns a verdict — allow, block, or human_review. Your code enforces it.
The agent's traffic flow is completely unchanged. The agent talks to your server normally. Your server makes a separate HTTP call to ShieldAgent and decides whether to execute the tool.
When to Use the Verdict API
| Situation | Recommended approach |
|---|---|
| You operate your own REST API that agents call | Verdict API — add POST /tenants/:tenantId/scan before your handler executes |
| You operate your own MCP server with tool handlers | Verdict API — add POST /tenants/:tenantId/scan in each tool handler |
| You want security scanning without changing agent routing | Verdict API — the agent's endpoint URL stays the same |
| You don't own the server (agents call a third-party) | Inline proxy — route agents through ShieldAgent instead |
| You want proxy blocking for routed calls in enforce mode | Inline proxy (Position 1) — ShieldAgent blocks before forwarding in enforce mode |
Quick Start
SDK examples have been retired. For a supported integration, use the OpenAPI reference.
Scan Request
The REST client calls POST /tenants/:tenantId/scan on the ShieldAgent API. Authenticate with a tenant API key (Bearer token).
{
"agentId": "agent-uuid", // OPTIONAL — omit if server cannot identify the agent
"clientHint": "Claude Desktop", // OPTIONAL — from MCP clientInfo.name, for best-effort matching
"toolName": "read_file",
"params": { "path": "/etc/passwd" },
"include_findings": false, // opt-in; requires verdictDetailedFindings tenant permission
"context": {
"transport": "mcp", // "mcp" | "rest" | "custom"
"sourceIp": "10.0.1.5", // optional — used for rate limiting
"sessionId": "sess-123" // optional — enables excessive agency detection
}
}Scan Response
Default (all tenants)
{
"action": "block", // "allow" | "block" | "human_review"
"reason": "Security threat detected", // generic — no detection detail
"riskScore": 87,
"auditEventId": "evt-uuid", // audit event was written
"reviewId": null // set when action is "human_review"
}Detailed findings ((requires include_findings: true + tenant permission))
{
"action": "block",
"reason": "Prompt injection detected in tool arguments",
"findings": [
{
"type": "injection",
"severity": "critical",
"detail": "Path traversal pattern detected"
}
],
"riskScore": 87,
"auditEventId": "evt-uuid",
"reviewId": null
}Detailed findings are disabled by default. Without tiering, an attacker with Verdict API access could iteratively probe which scanner caught their payload and craft evasion attempts. Enable only for trusted internal tooling via the tenant settings in the ShieldAgent dashboard.
Security Checks
The Verdict API applies the same comprehensive security checks as the inline proxy. Your request is evaluated against all configured protections before returning a verdict.
- Authentication and tenant validation
- Rate limiting (per-tenant and per-agent)
- Tool access control (approved tools allowlist)
- Policy evaluation against your configured rules
- Security scanning (prompt injection, DLP, tool drift, cross-origin, excessive agency)
- Risk score evaluation
- Audit trail logging
Agent Identity
agentId is optional. The MCP protocol does not expose agent identity — clientInfo from the MCP initialize handshake identifies the client software (e.g., "Claude Desktop"), not the individual agent. Your API or MCP server may not know which specific agent is calling.
| Scenario | What to send | Pipeline behavior |
|---|---|---|
| Your HTTP API authenticates agents and maps them to ShieldAgent agent IDs | agentId: "agent-uuid" | Full per-agent pipeline: per-agent policies, risk score, rate limits, tool allowlist |
| Your MCP server knows the client software (from MCP clientInfo.name) but not the agent | clientHint: "Claude Desktop" | ShieldAgent matches against registered agent names. If exactly one matches, uses it. Otherwise falls back to tenant-level. |
| Your server cannot identify the calling agent | (omit agentId and clientHint) | Tenant-level pipeline: tenant-wide policies, no per-agent risk or baseline |
Enforcement Observability
Because your code enforces the verdict (not ShieldAgent infrastructure), the audit trail cannot automatically confirm whether a block verdict was honored. Use POST /tenants/:tenantId/verdict-confirmations to submit your own execution report; ShieldAgent does not independently verify it.
SDK examples have been retired. For a supported integration, use the OpenAPI reference.
Compliance note
Tenants that do not call verdict confirmations appear as enforcement unknown in ShieldAgent compliance reports. For high-risk AI systems, EU AI Act Art. 9 addresses provider risk management, while Art. 11 and Annex IV address technical documentation. Describe your integration's actual enforcement where relevant. ShieldAgent includes the aggregate verdict confirmations enrollment rate as self-reported supporting telemetry, not independently verified enforcement or a rate required by those provisions.
Shared Responsibility Model
The Verdict API shifts enforcement from the inline proxy to your code. Whether your deployment blocks threats depends on your implementation; ShieldAgent documents its detection and pipeline capabilities, not the behavior of your code.
| Responsibility | Inline proxy | Verdict API |
|---|---|---|
| Threat detection | ShieldAgent | ShieldAgent |
| Policy evaluation | ShieldAgent | ShieldAgent |
| Risk scoring | ShieldAgent | ShieldAgent |
| Audit trail | ShieldAgent | ShieldAgent |
| Enforcement (blocking) | ShieldAgent — routed calls in enforce mode | Your code — confirmations are self-reported telemetry |
REST contract
SDK examples have been retired. For a supported integration, use the OpenAPI reference.
Related
- Architecture Overview →All deployment positions and integration patterns
- OpenAPI reference →Supported REST request and response schemas
- Risk Scoring Model →How riskScore in the verdict response is calculated
- Compliance Frameworks →EU AI Act Art. 9 and Annex IV implications for Verdict API deployments