Skip to main content

​
Overview

The Agent Triage Protocol implements a comprehensive security model with multiple authentication mechanisms to ensure secure communication between all components of the system.

​
Three-Tier Authentication System

ATP uses a three-tier authentication system that provides appropriate access controls for different system actors while maintaining security boundaries between components.

​
1. Administrative Authentication

Administrative tokens control service registration and system configuration. These long-lived tokens must be carefully protected and should only be used by system administrators during initial setup and service onboarding. Key characteristics:
  • Used only for service registration and system configuration
  • Highest privilege level in the system
  • Should be protected with strong security measures
  • Should be rotated periodically
  • Access should be tightly controlled and audited
The admin authentication layer prevents unauthorized parties from registering malicious services that could send spam notifications or impersonate legitimate AI agents. Example Authorization Header: 
Authorization: Bearer admin_token_abc123def456

​
2. Service Authentication

Each registered AI service receives a unique API key during the registration process. This key must be included as a Bearer token in the Authorization header for all service-initiated requests. Key characteristics:
  • Unique to each registered service
  • Used for sending notifications and receiving responses
  • Medium privilege level
  • Can only access operations related to the specific service
Service-specific keys provide several benefits:
  • Compromised keys affect only a single service
  • Usage can be tracked per service for billing or analytics
  • Keys can be rotated independently without affecting other services
Example Authorization Header: 
Authorization: Bearer sk_live_lovelace_abc123

​
3. User Authentication

End users authenticate with the ATP system through their client applications using OAuth 2.0 or similar protocols. User tokens authorize notification delivery and response submission. Key characteristics:
  • Associated with individual end users
  • Used for receiving notifications and submitting responses
  • Lowest privilege level
  • Can only access notifications intended for the specific user
The protocol supports flexible user authentication schemes to accommodate different deployment scenarios, from single-user installations to enterprise deployments with complex permission models. Example Authorization Header: 
Authorization: Bearer user_token_xyz789

​
Webhook Security

The ATP server authenticates callbacks to AI services using HMAC signatures. During service registration, the service provides a webhook secret. When delivering user responses, the ATP server includes an X-ATP-Signature header computed as: 
signature = HMAC-SHA256(request_body, webhook_secret)
The signature header format is: 
X-ATP-Signature: t=1622145123,v1=5257a869e7ecebb07c954661a7577d13c99705955e814274785a3174a535d5c7
Where:
  • t is the timestamp when the signature was generated
  • v1 indicates the signature algorithm version
  • The value after v1= is the hexadecimal representation of the HMAC signature
Services must verify this signature before processing responses to ensure the callback originated from the ATP server and hasn’t been tampered with. The signature also includes a timestamp to prevent replay attacks.

​
Signature Verification Example (Node.js)

const crypto = require('crypto');

function verifySignature(body, signature, secret) {
  // Extract timestamp and signature from header
  const [timeComponent, signatureComponent] = signature.split(',');
  const timestamp = timeComponent.split('=')[1];
  const signatureValue = signatureComponent.split('=')[1];
  
  // Check if timestamp is within acceptable range (5 minutes)
  const currentTime = Math.floor(Date.now() / 1000);
  if (currentTime - parseInt(timestamp) > 300) {
    return false; // Signature too old, possible replay attack
  }
  
  // Compute expected signature
  const expectedSignature = crypto
    .createHmac('sha256', secret)
    .update(body)
    .digest('hex');
  
  // Compare signatures using constant-time comparison
  return crypto.timingSafeEqual(
    Buffer.from(signatureValue, 'hex'),
    Buffer.from(expectedSignature, 'hex')
  );
}

​
Token Management

​
Token Expiration

To minimize security risks, the ATP protocol supports token expiration:
  • Administrative tokens: Typically valid for 30 days
  • Service API keys: Long-lived but can be manually revoked
  • User tokens: Should follow OAuth 2.0 best practices with refresh tokens

​
Token Rotation

The protocol supports secure token rotation:
  • Administrative tokens: Should be rotated manually on a regular schedule
  • Service API keys: Can be rotated through the administrative API
  • User tokens: Managed through the OAuth 2.0 refresh flow

​
Token Storage

All tokens should be securely stored:
  • Never store tokens in client-side code or public repositories
  • Use environment variables or secure key management systems
  • Encrypt tokens at rest in databases or configuration files

​
Transport Security

All ATP communication must use TLS 1.2 or higher to ensure data confidentiality and integrity during transit. The protocol does not support unencrypted HTTP connections in production environments. Additional transport security recommendations:
  • Enable HTTP Strict Transport Security (HSTS)
  • Implement certificate pinning for critical endpoints
  • Use strong cipher suites and disable outdated protocols
  • Validate server certificates on client side

​
Security Best Practices

When implementing the ATP protocol, follow these security best practices:
  1. Principle of Least Privilege: Grant only the minimum necessary permissions to each component
  2. Defense in Depth: Implement multiple layers of security controls
  3. Regular Auditing: Monitor authentication logs for suspicious activity
  4. Secure Defaults: Start with the most secure configuration by default
  5. Keep Dependencies Updated: Regularly update all libraries and dependencies
  6. Input Validation: Validate all inputs to prevent injection attacks
  7. Rate Limiting: Implement rate limiting to prevent brute force attacks
  8. Security Headers: Use appropriate security headers in HTTP responses
For more detailed security guidance, see the Security Guide section.
⌘I