Skip to content

Security

Last update: June 6, 2026

AI-Bridge for Cisco UC is built from the ground up for regulated environments, critical infrastructure, and data-sovereign organizations. Security is not a layer added on top — it is the foundation.

Every component follows a defense-in-depth architecture: multiple independent controls are layered so that no single failure opens a breach.

🛡 Security at a Glance

Layer What it does
🌩 Air-gapped No cloud, no telemetry, no outbound connections — ever
🐳 Docker hardening Non-root container, read-only filesystem, no-new-privileges, multi-stage build
🌐 Transport TLS 1.2+ enforced, DNS rebinding protection, strict header validation
👤 Authentication RS256 JWT (RSA-4096) or full OAuth 2.1 client_credentials flow
👥 Authorization RBAC with per-tool, per-product, per-protocol enforcement
📁 Data isolation Per-client encrypted directory — secrets never cross client boundaries
🔑 Credentials at rest AES-128-CBC + HMAC-SHA256 (Fernet), per-client key via PBKDF2-SHA512
🔍 Host verification SSH fingerprint trust + HTTPS certificate pinning to Cisco UC nodes
⛔ Brute-force protection Per-IP Fail2Ban + per-client sliding window rate limiting
📝 Audit trail Structured JSON audit log — every auth, action, and anomaly recorded
📦 Software integrity RSA-PSS signature over SHA-512 manifest — verified at startup
💾 Encrypted backups RSA-OAEP-SHA512 + AES-256-GCM hybrid — decryptable only with your private key
📊 CI scanning Automated SAST, secret scan, CVE audit, MCP YARA scan + signed SBOM on every push

🌩 Air-Gapped & Sovereign Design

AI-Bridge for Cisco UC contains zero cloud dependencies:

  • Designed for classified, government, and critical infrastructure networks.
  • Air-gapped model: the entire operational chain can run without any internet connectivity
  • The server only connects to the Cisco UC nodes you explicitly configure.
  • No external service, no telemetry, no analytics, no home mechanism.
  • Licensing is offline — licenses are RS256-signed JWT files installed locally. No license server, no online activation.

🐳 Docker Security Hardening

When deployed with Docker, additional security controls are applied:

Measure Description
Non-root user Container runs as mcpadmin (UID 1000) — never as root
Read-only filesystem Container filesystem is immutable (read_only: true)
No privilege escalation no-new-privileges:true prevents setuid/setgid exploits
Minimal tmpfs /tmp is a 64 MB tmpfs — no persistent writable area outside volumes
Multi-stage build Build tools and compilers are absent from the production image
Bind-mount volumes Runtime data is isolated on the host; .env is mounted read-only

🌐 Transport Security

All client-to-server communications are encrypted and strictly validated.

  • Mandatory encryption — All communications are encrypted over HTTPS.
  • TLS 1.2+ only — SSL, TLS 1.0 and TLS 1.1 are explicitly disabled.
  • Certificate management — CA-signed or auto-generated self-signed certificates supported.
  • DNS rebinding protection — Every request is validated against the configured allowed origins. Requests with mismatched or forged Host headers are rejected.
  • Strict header validation — Origin, Content-Type, and custom headers are enforced on all HTTP endpoints.

👤 Authentication

Two authentication modes are supported, selectable per deployment:

Clients authenticate with RS256-signed JSON Web Tokens using an auto-generated RSA-4096 key pair.

  • Long-lived tokens distributed to registered clients at provisioning time.
  • Revocable via the /revoke endpoint (RFC 7009).
  • Active token revocation with JTI blacklist and automatic expiry cleanup.

Full OAuth 2.1 flow with two supported grants:

  • Authorization Code + PKCE (RFC 7636 S256) — browser-based login for interactive clients (AI IDEs)
  • Client Credentials (RFC 6749 §4.4) — headless M2M token issuance
  • Token revocation via /revoke (RFC 7009)
  • Authorization Server Metadata: /.well-known/oauth-authorization-server (RFC 8414)
  • Protected Resource Metadata: /.well-known/oauth-protected-resource (RFC 9728) — required by MCP 2025-03-26 compliant clients
  • Supports HTTP Basic auth and POST client auth methods
  • Hybrid JWT + OAuth 2.1 mode supported for mixed client environments

👥 Authorization — RBAC

Every tool invocation is authorized through a Role-Based Access Control engine before execution.

  • Predefined profiles: admin, operator, auditor — each with a specific scope of allowed operations.
  • Custom profiles — organizations can define their own profiles as JSON files for fine-grained control.
  • Per-product granularity — separate permissions per product module.
  • Per-protocol granularity — AXL operation prefix filtering, SSH command allowlists, RIS API class restrictions.
  • Per-tool enforcement — every MCP tool declares its required profile level; unauthorized calls are rejected before any UC API is contacted.

📁 Per-Client Data Isolation

Each registered client operates in a fully isolated environment:

  • Dedicated directory with its own secrets, credentials, reports, and configuration.
  • No data sharing between clients — credentials and reports are never accessible cross-client.
  • Automatic cleanup — when a client is decommissioned, its directory and all associated data are purged.

🔑 Credential Encryption at Rest

All stored Cisco UC credentials are encrypted using Fernet (AES-128-CBC + HMAC-SHA256).

  • Encryption keys are derived per client from the client UUID + a server-side salt using PBKDF2-SHA512 with 600,000 iterations (NIST SP 800-132 compliant).
  • The server salt is generated once and stored in a restricted-access file.
  • No credential is ever stored in plaintext — not in memory cache after idle timeout, not on disk.

🔍 Host Identity Verification

AI-Bridge verifies the identity of every Cisco UC node before sending any data.

  • SSH connections — Trust-On-First-Use (TOFU) model: the fingerprint of the remote host is captured and stored on first connection. All subsequent connections verify the fingerprint — a mismatch triggers an alert and blocks the operation.
  • HTTPS connections — Certificate verification is enforced for all AXL API calls. Certificate pinning is supported for maximum assurance.

⛔ Brute-Force & Rate-Limit Protection

Independent mechanisms guard against abuse:

Fail2Ban (per IP): Tracks authentication failures per source IP. After a configurable number of failures within a sliding window, the IP is automatically blocked for a configurable duration. All events are recorded in the audit log.

Rate Limiting (per client): Each authenticated client is subject to a per-tool-category sliding window rate limit. Requests exceeding the limit return HTTP 429 and are logged.

📝 Audit Trail

Every security-relevant event is written to a dedicated audit.log in structured JSON format.

Event category What is logged
AUTH Login success/failure, token issued/revoked, IP address, client identity
ACTIONS Every MCP tool call — client, tool name, host, result status
RATE_LIMITED Client and IP rate limit events
CREDENTIAL Store, update, delete credential operations
TRUSTED SSH fingerprint trust decisions
WRITTEN/EXPORTED Report generation and PDF export
SERVER Startup, shutdown, license state changes
TRANSPORT TLS alerts, header violations, DNS rebinding attempts

Log injection is prevented by sanitizing control characters in all logged values (CWE-117 mitigation).

📦 Software Integrity Verification

Every release is signed. Install / Upgrade package integrity is verified via SHA-512 checksums before installation.

Additionally, the integrity of all project files is verifiable at any time. - An SHA-512 manifest (manifest.json) covers every source file. - The manifest is signed with RSA-PSS over SHA-512 (RSA-4096), producing manifest.sig. - Integrity is verified at startup and periodically monitored by a background watchdog. - Any tampering with source files will be detected and reported before the server operates.

💾 Encrypted Backups

Backups of client data are protected with hybrid encryption:

  • A random AES-256-GCM session key encrypts the backup archive.
  • The session key is wrapped with your RSA-4096 public key using RSA-OAEP with SHA-512 (MGF1-SHA512).
  • Only the holder of the private key can decrypt — the server itself cannot read its own backups without the key.
  • An SHA-512 sidecar file ensures backup integrity before any restore attempt.
  • Optional SFTP export with SSH key or encrypted password authentication; configurable remote retention policy.
  • Mandatory SFTP hostkey verification (anti-MITM): the remote server hostkey must be pre-registered in BACKUP_SFTP_KNOWN_HOSTS (OpenSSH known_hosts format, populated via ssh-keyscan). If the file is missing or the host is unknown, the transfer aborts before any credential is sent.

📊 CI Security Scanning

Every push to main triggers an automated security pipeline. CI fails on any unsafe finding not explicitly documented in the allowlist.

Stage Tool Scope / Engine
MCP YARA scan cisco-ai-mcp-scanner by Cisco AI Defense Static / offline (no live server, no API key) — YARA rules covering prompt injection, data exfiltration and tool abuse patterns across all MCP tools, prompts and resources
SAST bandit Python source analysis over lib/, servers/, scripts/
Lint / static checks ruff + mypy Style, common bug patterns and static type checking
Secret detection gitleaks Full Git history scanned for committed credentials / tokens
Container image scan trivy image OS packages + Python dependencies in the published Docker image (CVE + misconfigurations)
Dependency CVE audit pip-audit Resolved runtime + dev dependency set (from uv export --no-dev)
SBOM cyclonedx-py CycloneDX 1.5 JSON SBOM published as a CI artifact, signed offline (RSA-PSS / SHA-512) with the editor private key and verifiable with the embedded lib/editor_public.pem
Unit & coverage pytest + pytest-cov Full unit-test suite with ≥ 88 % coverage gate (lib/, servers/, scripts/)

Reproducible locally

All scanners above ship in the dev dependency group of pyproject.toml and can be re-run on a developer workstation with uv sync then bandit, pip-audit, gitleaks detect, trivy image ai-bridge-for-cisco-uc:latest, pytest, and python tests/tests_check_mcp_scan.py (which validates the MCP-scanner JSON output against the known false-positive allowlist).

✉ Vulnerability Reporting

If you discover a security vulnerability, please report it privately:

Responsible disclosure is appreciated. All reports are treated with confidentiality.

We sincerely thank every researcher and user who takes the time to report a vulnerability — your contribution directly strengthens the security of AI-Bridge for Cisco UC and the organizations that rely on it.

✅ Standards & Compliance

Standard / Framework Coverage
RFC 6749 OAuth 2.0 Authorization Framework
RFC 7009 Token Revocation
RFC 7636 Proof Key for Code Exchange (PKCE) — S256 code challenge
RFC 7519 JSON Web Tokens (JWT)
RFC 8414 OAuth 2.0 Authorization Server Metadata
RFC 9728 OAuth 2.0 Protected Resource Metadata
NIST SP 800-132 PBKDF2 key derivation (600k iterations, SHA-512)
OWASP Top 10 Input validation, log injection (CWE-117), transport security
CWE-117 Log injection prevention via control character sanitization