Skip to main content

​
Bearer Token Authentication

Rampart uses bearer token authentication for API access. The token is automatically generated when you install the service.

​
Token Location

The token is stored in: 
~/.rampart/token

​
Using the Token

Include the token in the Authorization header: 
TOKEN="$(cat ~/.rampart/token)"
curl -H "Authorization: Bearer $TOKEN" \
  http://127.0.0.1:9090/v1/status

​
Header Format

Authorization: Bearer <token>
Never commit your token to version control or expose it in logs. The token grants full access to the Rampart API.

​
Token Management

​
View Current Token

Display the current bearer token: 
rampart token

​
Rotate Token

Generate and persist a new bearer token: 
rampart token rotate
Skip confirmation prompt: 
rampart token rotate --force
Rotating the token invalidates all existing API clients. You’ll need to restart rampart serve and update any scripts or integrations that use the old token.

​
Authentication Methods by Endpoint

Different endpoints support different authentication methods:

​
Bearer Token Only

Most endpoints require the Authorization: Bearer <token> header:
  • POST /v1/tool/{toolName}
  • POST /v1/preflight/{toolName}
  • GET /v1/approvals
  • POST /v1/approvals
  • GET /v1/status
  • GET /v1/policy
  • All audit endpoints

​
No Authentication Required

Health check endpoint is public: 
curl http://127.0.0.1:9090/healthz

​
Multiple Authentication Methods

​
Event Stream

GET /v1/events/stream accepts either: Header-based: 
curl -N -H "Authorization: Bearer $TOKEN" \
  http://127.0.0.1:9090/v1/events/stream
Query parameter: 
curl -N "http://127.0.0.1:9090/v1/events/stream?token=$TOKEN"
Query parameter authentication is provided for clients that cannot set custom headers (e.g., EventSource in browsers).

​
Approval Resolution

POST /v1/approvals/{id}/resolve accepts:
  1. Bearer token (standard)
  2. Signed URL with sig and exp query parameters (when signing is enabled)
Signed URL example: 
curl -X POST "http://127.0.0.1:9090/v1/approvals/01J.../resolve?sig=abc&exp=1234" \
  -H "Content-Type: application/json" \
  -d '{"approved":true}'
Signed URLs are generated by the server when webhook notifications are configured. They include an HMAC signature and expiration timestamp.

​
Security Recommendations

​
File Permissions

Keep token file permissions restrictive: 
chmod 600 ~/.rampart/token

​
Token Rotation

Rotate tokens periodically or after suspected exposure: 
rampart token rotate --force

​
Environment Variables

When using RAMPART_TOKEN in scripts, ensure the environment is secure: 
# Good: read from secure file
export RAMPART_TOKEN="$(cat ~/.rampart/token)"

# Bad: hardcoded in script (never do this)
export RAMPART_TOKEN="abc123..."

​
Signed URLs

Signed approval URLs are time-limited and single-use:
  • They expire at the exp timestamp
  • They cannot be replayed after the approval is resolved
  • HMAC signature ensures authenticity
Treat signed URLs as sensitive. They grant one-time approval resolution without requiring the bearer token.

​
Error Responses

​
Missing Token

curl http://127.0.0.1:9090/v1/status
Response: 
{
  "error": "missing authorization header"
}
Status: 401 Unauthorized

​
Invalid Token

curl -H "Authorization: Bearer invalid" \
  http://127.0.0.1:9090/v1/status
Response: 
{
  "error": "invalid authorization token"
}
Status: 401 Unauthorized

​
Expired Signature (Signed URLs)

curl -X POST "http://127.0.0.1:9090/v1/approvals/01J.../resolve?sig=abc&exp=1" \
  -H "Content-Type: application/json" \
  -d '{"approved":true}'
Response: 
{
  "error": "invalid or expired signature"
}
Status: 401 Unauthorized

​
Next Steps

Tool Evaluation

Evaluate tool calls with the API

Status

Check server status and health

Build docs developers (and LLMs) love

Get started for freeTalk to us