Overview
AI agents interact with GaiterGuard through three core endpoints:POST /proxy for submitting requests, GET /status/:actionId for polling approval status, and POST /proxy/execute/:actionId for executing approved requests.
This guide covers the complete integration flow with real code examples.
Authentication
All agent requests require anAgent-Key header. Agent keys are provisioned through the dashboard and start with the agt_ prefix.
Required Headers
Every agent request must include:string
required
The agent’s API key in the format Obtained from the dashboard when creating an agent.
agt_<64 hex characters>Example:string
required
Unique identifier for this request to prevent duplicate execution.Required for: POST and PATCH requestsFormat: Any unique string (UUID recommended)Example:
If the same idempotency key is reused, the cached response from the first request is returned.
Authentication Flow
The gateway authenticates agents using theAgent-Key header (see backend/src/middleware/auth.ts:65):
- Extract
Agent-Keyheader from request - Validate format (must start with
agt_) - Hash the key using SHA-256
- Query
agentstable for matching key hash - Verify agent is active (
isActive = true) - Update
lastUsedAttimestamp (fire-and-forget)
401 Unauthorized- Missing, invalid, or revoked Agent-Key403 Forbidden- Agent not scoped to the requested service
Request Flow
Step 1: Submit Proxy Request
Submit a request to be proxied through the gateway. Endpoint:POST /proxy
Request body:
string
required
The full URL to proxy to. Must start with the
baseUrl of a service the agent is scoped to.SSRF Protection: The gateway validates that:- Hostname matches the registered service
- Path starts with the service’s base path
- Target is not a private IP range
string
required
HTTP method:
GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONSobject
Request headers to forward. Do not include authentication headers - the gateway injects credentials automatically.Automatically injected:
Authorization: Bearer <token>(for bearer/oauth2 auth)Authorization: Basic <base64>(for basic auth)- Custom API key headers (for api_key auth)
string
Request body as a JSON-stringified string. Omit for GET/HEAD/DELETE.
string
required
Plain English description of what this request does. Used by the LLM for risk assessment.Good intent:
- “Fetch the latest 10 orders for daily reporting”
- “Create a new customer record for signup flow”
- “Charge customer $5.00 for subscription renewal”
- “get data” (too vague)
- “Read orders” for a DELETE request (mismatch → high risk score)
string
Unique request identifier. Required for POST and PATCH. Prevents duplicate execution.
Response Scenarios
- Low Risk (2xx)
- High Risk (428)
- Errors
Request forwarded immediately and executed.Response:Headers:
X-Proxy-Status: forwardedX-Idempotency-Status: processed(if idempotency key used)
Step 2: Poll for Approval
When a request is blocked (HTTP 428), poll the status endpoint until a terminal state is reached. Endpoint:GET /status/:actionId
Polling pattern:
- Poll every 5-10 seconds
- Continue until status is
APPROVED,DENIED,EXPIRED, orEXECUTED - Timeout after ~10 minutes (75 polls at 8 seconds)
- PENDING
- APPROVED
- DENIED
- EXPIRED
- EXECUTED
Step 3: Execute Approved Request
Once status isAPPROVED, execute the request.
Endpoint: POST /proxy/execute/:actionId
No request body needed - the gateway replays the original stored request with fresh credentials.
409 Conflict- Action status is not APPROVED (check current status)410 Gone- Approval expired; resubmit via POST /proxy
Error Handling
HTTP Status Codes
error
Missing, invalid, or revoked Agent-KeyAction: Verify Agent-Key is correct and agent is active
error
Agent not scoped to the target serviceAction: Grant service access in dashboard → Agents → Edit → Service Scope
error
- Service not found matching targetUrl
- Action not found (ownership check failed)
error
- Idempotency key conflict (request already processing)
- Cannot execute action with current status
error
Approval expired before executionAction: Resubmit the original request via POST /proxy
success
Request blocked for human approval (not an error)Action: Enter polling flow
error
Upstream service returned an errorAction: Check upstream service health and request validity
error
Upstream request exceeded 30 second timeoutAction: Retry or contact service owner
Risk Score Reference
The LLM assigns a base risk score by HTTP method (seebackend/src/services/risk.service.ts:1):
The final score is adjusted based on:
- Intent clarity (vague intent → higher score)
- Intent-body mismatch (“read” intent with DELETE → very high score)
- Sensitive keywords (“delete”, “destroy”, “drop”, etc.)
- API documentation context (registered with service)
Complete Integration Example
Full Python script with polling and execution:Next Steps
Agent Skill
Install the Claude agent skill for automatic integration
Configuration
Tune risk threshold and approval TTL