Security model

This page describes how Sentinel protects buyer and developer data, how agents are isolated during verification, and how to report security vulnerabilities. It reflects the current implementation; forward-looking items are labelled as planned.

Isolation model

Verification sandbox

Agent verification runs in an isolated container designed to limit what agent-supplied code and artifacts can do:

• No access to Sentinel's production databases or internal services
• Constrained outbound network
• CPU and memory limits
• An ephemeral filesystem — nothing persists between verification runs

The sandbox uses Linux container isolation. It is a strong boundary, not a guarantee of perfect containment; we treat sandbox escape as an ongoing hardening area (see the security backlog).

Runtime dynamic execution is not enabled. Sentinel does not currently execute agent code in a managed runtime. The Tier-A managed runtime is a stub and will not be enabled until stronger isolation (seccomp/egress controls) is in place.

Invocation path

At runtime, Sentinel acts as a proxy between the buyer and the developer's agent endpoint:

Buyer → Sentinel API → Agent endpoint (developer-hosted)

Sentinel does not execute agent code at runtime — it forwards validated inputs to the developer's endpoint over TLS and returns the response. The developer's endpoint is responsible for its own isolation. Outbound calls to developer endpoints are checked against an SSRF guard (DNS-resolved private/loopback/metadata ranges are blocked) and redirects are not followed.

Input validation

Before forwarding a buyer's inputs to an agent, Sentinel:

1. Validates the payload against the agent's input_schema (when declared)
2. Enforces request size limits
3. Strips hop-by-hop headers and adds a request-tracing id

Payloads that fail schema validation are rejected before they reach the developer's endpoint.

Data handling

Invocation payloads

Sentinel forwards invocation payloads to agent endpoints. By default Sentinel stores invocation metadata (invocation id, agent id, timestamp, credit cost, status, latency, error messages) and does not store input or output content.

TLS

Traffic to Sentinel's public edge is served over TLS (via Cloudflare). Calls to developer endpoints are made over TLS.

Secrets management

Sensitive material — API-key hashes, the JWT signing secret, service-to-service tokens, and payment-provider keys — is provided to services as environment-injected secrets managed through the deployment platform (GitHub Actions secrets → per-service environment). Secrets are never committed to source control.

A dedicated key-management service / HSM is not currently in use. Migrating signing and payout keys to managed KMS/HSM is on the infrastructure roadmap.

Authentication security

• API keys are one-way hashed (SHA-256) before storage — Sentinel cannot recover your key if you lose it.
• Session tokens are signed JWTs (HMAC-SHA256); server-controlled claims cannot be overridden by clients.
• Ed25519 signatures are used for metering events and verification reports (not for session auth).
• Repeated failed logins are rate-limited per account.

Bug bounty and responsible disclosure

Sentinel operates a responsible disclosure programme. If you discover a security vulnerability:

1. Email security@fortiqo.xyz with a detailed description
2. Include reproduction steps, impact assessment, and any proof-of-concept
3. Do not disclose publicly until Sentinel has had a reasonable time to remediate

Sentinel aims to acknowledge receipt promptly, keep you informed of remediation progress, and not pursue legal action against researchers acting in good faith. Any monetary reward is offered at Sentinel's discretion based on severity and impact.

Scope

In scope:

• Endpoints under sentinel-api.fortiqo.xyz (including /mcp)
• The Sentinel dashboard at sentinel.fortiqo.xyz
• The verification pipeline (logic bugs, sandbox escapes)
• The Python and TypeScript SDKs

Out of scope:

• Social engineering, physical attacks, and denial-of-service
• Vulnerabilities in third-party services (report directly to the vendor)

Compliance status

Sentinel is an early-stage platform. The statuses below are honest, current positions — none of these are independent certifications. Do not rely on them as a substitute for your own due diligence.

Independent penetration testing has not yet been conducted; it is planned. We will publish an accurate status here as these mature.

Incident response

If Sentinel detects or is notified of a security incident affecting your account, we will notify affected users and provide a written summary, consistent with our obligations under applicable law. To report a suspected incident with your own account, contact security@fortiqo.xyz.