Security
AgentBridge is built with security as a first-class concern. This page describes exactly how your OAuth tokens, API keys, and execution data are protected at every layer of the system — from encryption at rest to transport security and audit logging.
If you believe you have found a security vulnerability in AgentBridge, please email info@agentbridge.in immediately rather than opening a public issue. We operate a 90-day coordinated responsible disclosure timeline.
Token Encryption #
When you connect an integration, the OAuth access token and refresh token are immediately encrypted and stored in the token vault. AgentBridge uses AES-256-GCM — an authenticated encryption algorithm that provides both confidentiality and integrity protection.
| Property | Value | Notes |
|---|---|---|
| Algorithm | AES-256-GCM | NIST-approved authenticated encryption |
| Key size | 256 bits (32 bytes) | Maximum strength for AES |
| IV (nonce) | 96 bits (12 bytes) | Randomly generated per encryption operation |
| Auth tag | 128 bits (16 bytes) | Prevents ciphertext tampering and oracle attacks |
| Key storage | Separate from database | Environment secret, not in application code or database |
| Decryption timing | At tool execution time only | Plaintext exists in memory only during the provider API call |
| Plaintext in logs | Never | Tokens are never written to application logs, error reports, or API responses |
The encryption key is never stored in the database. Compromising the database without the encryption key yields only unusable ciphertext. The decrypted token exists only transiently in application memory during the upstream provider API call, after which it is immediately garbage-collected.
OAuth Security #
AgentBridge implements OAuth 2.0 with the following security properties:
- State parameter — A cryptographically random state value is generated per OAuth flow and verified on callback, preventing cross-site request forgery (CSRF) attacks. The state is stored server-side and validated on redirect.
- PKCE (Proof Key for Code Exchange) — Used where the provider supports it (Google OAuth 2.0), preventing authorization code interception attacks. A random code verifier and its SHA-256 challenge are generated per flow.
- Redirect URI validation — Only pre-registered redirect URIs are accepted. AgentBridge validates the exact redirect URI on every OAuth callback, rejecting requests with modified or unexpected redirect destinations.
- Automatic token refresh — Expired access tokens are transparently refreshed using the stored refresh token before each tool call. The new tokens are re-encrypted and stored. Users never see token expiry errors.
- Minimum required scopes — Each provider integration requests only the OAuth scopes strictly necessary for its tool catalog. No over-broad permissions are requested.
- Secure popup flow — OAuth authorization happens in a popup window. The popup closes automatically after the redirect is processed, preventing the authorization code from being visible in the browser address bar.
API Key Security #
API keys are handled with the same care as passwords:
- Keys are hashed with SHA-256 before storage in the database. The full plaintext key is displayed exactly once at creation time and cannot be retrieved afterward — not by the user, not by AgentBridge administrators, not by anyone.
- The prefix (
ab_live_) is stored in plaintext alongside the hash solely for display identification in the Dashboard. The prefix alone is not sufficient to authenticate. - Constant-time comparison is used when validating incoming keys against stored hashes, preventing timing oracle attacks that could leak hash information through response time variations.
- Keys can be revoked instantly — deletion takes effect for all subsequent requests immediately, with zero propagation delay.
- Key creation is rate-limited to prevent abuse and brute-force key generation attacks.
TLS & Transport Security #
- All traffic between clients and AgentBridge uses TLS 1.2 or TLS 1.3. Connections using older protocol versions (TLS 1.0, TLS 1.1, SSLv3) are rejected.
- HSTS (HTTP Strict Transport Security) is enabled with
max-age=31536000(1 year) andincludeSubDomains, preventing protocol downgrade attacks. - Plain HTTP requests are redirected to HTTPS with a
301 Moved Permanentlyresponse. API keys sent over plain HTTP are still at risk during the initial request before the redirect, so always usehttps://URLs. - TLS certificates are auto-renewed via Let's Encrypt. Certificate transparency logs are monitored for unauthorized certificate issuance.
- Upstream calls to provider APIs (Notion, Slack, GitHub, Google) are also made exclusively over TLS.
Audit Logging #
Every significant action in AgentBridge is logged with a full audit trail. Audit logs are retained for the lifetime of the account.
| Event | Logged Fields |
|---|---|
| Tool execution | Actor (user ID), provider, tool name, timestamp, latency (ms), HTTP status, execution ID, result status (success/error) |
| Integration connect | Actor, provider slug, timestamp, connection method (OAuth/PAT) |
| Integration disconnect | Actor, provider slug, timestamp |
| API key create | Actor, key name, scope, timestamp, key prefix (for identification) |
| API key delete | Actor, key name, timestamp |
| Login | Actor, IP address, user agent, timestamp, success/failure |
| Logout | Actor, timestamp |
What is not logged in plaintext: Raw tool parameters (the params object) are never stored in plaintext audit logs. Provider error bodies from failed executions are stored only in the encrypted execution detail record, accessible only to the account owner via the Dashboard or GET /logs/:id.
Rate Limiting #
AgentBridge enforces rate limits at two levels to protect both the platform and individual accounts from abuse:
- Per-key limits — Each API key is rate-limited independently. Abuse from one key cannot consume another key's quota, even within the same account.
- Per-account limits — Aggregate limits are enforced per account based on the plan tier (Free: 100/mo, Starter: 5k/mo, Growth: 50k/mo).
- Sliding window algorithm — Limits are tracked using a sliding window to prevent burst exploitation at window boundaries (unlike fixed-window approaches that allow 2x burst at boundaries).
- Transparent headers — Rate limit state is returned in every response via
X-RateLimit-Limit,X-RateLimit-Remaining, andX-RateLimit-Resetheaders, enabling proactive throttling.
See Rate Limits for detailed per-plan limits and the Authentication guide for header descriptions.
Email Verification #
All AgentBridge accounts require email verification before API keys can be created or integrations connected. This prevents abuse from throwaway accounts and ensures the account owner can be contacted in case of suspicious activity. Unverified accounts can log in to the Dashboard but cannot perform any API operations.
Data Residency #
| Data Type | Storage Location | Encryption |
|---|---|---|
| User accounts and profiles | AWS ap-south-1 (Mumbai) | At rest (EBS encryption) |
| Encrypted OAuth tokens | AWS ap-south-1 (Mumbai) | AES-256-GCM + EBS encryption |
| API key hashes | AWS ap-south-1 (Mumbai) | SHA-256 hashed + EBS encryption |
| Execution logs | AWS ap-south-1 (Mumbai) | At rest (EBS encryption) |
| Application servers | AWS ap-south-1 (Mumbai) | TLS in transit |
All data is stored exclusively in the AWS ap-south-1 (Mumbai) region. Enterprise customers requiring a different data residency region (EU, US, etc.) should contact info@agentbridge.in to discuss dedicated deployment options.
Responsible Disclosure #
We take security reports seriously and are committed to resolving confirmed vulnerabilities as quickly as possible.
- Contact: info@agentbridge.in
- PGP key: Available on request
- Response time: We acknowledge receipt within 48 hours
- Triage time: Initial severity assessment within 5 business days
- Disclosure timeline: 90 days from initial report, coordinated with the reporter
- In scope:
api.agentbridge.in,agentbridge.in,docs.agentbridge.in, theagentbridge-sdknpm package - Out of scope: Social engineering, physical attacks, DDoS, issues in third-party dependencies with existing CVEs, vulnerabilities in provider APIs
We do not operate a bug bounty program at this time, but we will acknowledge researchers publicly (with their permission) when a valid report is confirmed and resolved.