Skip to main content

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 an Agent-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 agt_<64 hex characters>Example:
Obtained from the dashboard when creating an agent.
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 the Agent-Key header (see backend/src/middleware/auth.ts:65):
  1. Extract Agent-Key header from request
  2. Validate format (must start with agt_)
  3. Hash the key using SHA-256
  4. Query agents table for matching key hash
  5. Verify agent is active (isActive = true)
  6. Update lastUsedAt timestamp (fire-and-forget)
Error responses:
  • 401 Unauthorized - Missing, invalid, or revoked Agent-Key
  • 403 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:
Request fields:
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, OPTIONS
object
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”
Bad intent:
  • “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.
The Idempotency-Key header takes precedence over this field if both are provided.

Response Scenarios

Request forwarded immediately and executed.Response:
Headers:
  • X-Proxy-Status: forwarded
  • X-Idempotency-Status: processed (if idempotency key used)
The agent receives the upstream service’s response directly.

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, or EXECUTED
  • Timeout after ~10 minutes (75 polls at 8 seconds)
Response shapes by status:
Waiting for human review. Continue polling.

Step 3: Execute Approved Request

Once status is APPROVED, execute the request. Endpoint: POST /proxy/execute/:actionId No request body needed - the gateway replays the original stored request with fresh credentials.
Success response: Returns the upstream service response with header:
Error responses:
  • 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)
Action: Verify service is registered and agent is scoped to it
error
  • Idempotency key conflict (request already processing)
  • Cannot execute action with current status
Action: Wait for in-flight request to complete, or check action 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 (see backend/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