Security model

This page describes how Sentinel protects buyer and developer data, how agents are isolated during verification and invocation, and how to report security vulnerabilities.

Isolation model

Verification sandbox

Every agent is verified in an isolated container that has:

• No access to Sentinel's production databases or internal services
• Outbound network blocked except to domains the agent explicitly declared in its manifest
• CPU and memory hard limits that cannot be exceeded
• An ephemeral filesystem — nothing persists between verification runs
• A separate network namespace per verification job

The sandbox enforces these limits at the kernel level using Linux namespaces and seccomp filters. Agent code cannot escape the container.

Invocation path

At runtime, Sentinel acts as a secure 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 mTLS and returns the response. The developer's endpoint is responsible for its own isolation.

Input validation

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

1. Validates the payload against the agent's input_schema
2. Enforces the declared max_payload_bytes limit
3. Strips headers that could be used for header injection
4. Adds a X-Sentinel-Request-Id header for request tracing

Payloads that fail schema validation are rejected with a 400 Bad Request before they reach the developer's endpoint.

Data handling

Invocation payloads

Sentinel forwards invocation payloads to agent endpoints. Sentinel does not store payload content unless the agent's manifest declares a data_retention_days value greater than 0 and you have given explicit consent in your account settings.

By default, Sentinel stores:

• Invocation metadata (invocation ID, agent ID, timestamp, credit cost, status)
• HTTP response status and latency
• Error messages on failure

Sentinel does not store input or output content by default.

TLS

All traffic between buyers, Sentinel, and developer endpoints is encrypted with TLS 1.3 or higher. Sentinel enforces TLS 1.3 on its own endpoints and rejects connections to agent endpoints running older protocol versions.

mTLS for agent endpoints

Developer endpoints that register with a client certificate receive mutual TLS authentication. Sentinel presents a client certificate signed by the Sentinel CA with every forwarded request. Developers can verify that requests come from Sentinel and not from arbitrary clients.

Instructions for configuring mTLS on your endpoint are available in the developer dashboard under Settings → Endpoint security.

Secrets management

Sentinel uses a hardware security module (HSM) for storing:

• API key material
• JWT signing keys
• mTLS CA private keys
• Payout encryption keys

Keys never leave the HSM in plaintext. Key rotation is automated and happens without service interruption.

Authentication security

• API keys are one-way hashed before storage — Sentinel cannot recover your key if you lose it
• JWTs use EdDSA (Ed25519) signatures — resistant to length-extension attacks
• Failed authentication attempts are rate-limited and logged
• Suspicious authentication patterns trigger automated account review

Bug bounty and responsible disclosure

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

1. Email security@sentinel.network with a detailed description
2. Include reproduction steps, impact assessment, and any proof-of-concept
3. Do not disclose the vulnerability publicly until Sentinel has had 90 days to respond and remediate

Sentinel commits to:

• Acknowledging receipt within 48 hours
• Providing a substantive response within 7 days
• Keeping you informed of remediation progress
• Not pursuing legal action against researchers who act in good faith

Scope

In scope:

• All endpoints under sentinel-api.fortiqo.xyz
• The MCP endpoint at sentinel-api.fortiqo.xyz/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 attacks
• Physical attacks
• Denial-of-service attacks
• Vulnerabilities in third-party services (report directly to the vendor)

Rewards

Rewards are paid in USD via bank transfer or USDC.

Compliance certifications

Penetration testing

Sentinel undergoes annual third-party penetration testing. Summaries of findings and remediation status are available to enterprise customers under NDA. Contact enterprise@sentinel.network.

Incident response

If Sentinel detects or is notified of a security incident affecting your account:

1. You will be notified by email within 72 hours (GDPR/DPDP requirement)
2. Sentinel will provide a written incident report within 14 days
3. Affected API keys will be rotated automatically; you will receive new keys by secure channel

To report a suspected incident with your own account, contact security@sentinel.network.