Security

1. Security Posture

Seldon is designed with security as a core architectural principle:

• No free-form input: The playground accepts only selector IDs (industry, vertical, stack, scenario). All execution parameters are resolved server-side from a versioned, immutable catalog.
• Sandbox isolation: Each playground run operates against isolated kernel tables. Runs are serialized and time-bounded.
• Rate limiting: API endpoints enforce per-IP and per-session rate limits. Session counts are capped globally.
• Deterministic execution: The same catalog version and selection IDs always produce the same result. All outputs include cryptographic hashes for verification.
• Append-only ledger: All enforcement decisions are recorded in a hash-chain ledger. Records cannot be modified or deleted after creation.

2. Responsible Disclosure

If you discover a security vulnerability in Seldon, we ask that you report it responsibly. Please contact:

security@islandai.io

When reporting, please include:

• A description of the vulnerability and its potential impact.
• Steps to reproduce the issue.
• Any relevant screenshots, logs, or proof-of-concept code.

3. Disclosure Timeline

We commit to the following response timeline:

• Acknowledgment: Within 48 hours of receiving your report.
• Initial assessment: Within 5 business days.
• Resolution or mitigation: Best effort within 30 days, depending on severity.

We will keep you informed of progress and credit you in any public disclosure (unless you prefer to remain anonymous).

4. Scope of Testing

The following are in scope for responsible security testing:

• The Seldon playground web application at seldon.islandai.io.
• The public API endpoints (/api/catalog, /api/run, /api/export/*, /api/health).
• Authentication and session management logic.
• Input validation and injection testing on API endpoints.

The following are out of scope:

• Denial-of-service attacks or load testing.
• Social engineering or phishing against team members.
• Physical attacks against infrastructure.
• Third-party services or infrastructure not operated by IslandAI.
• Automated scanning that generates excessive traffic.

5. Safe Harbor

Security researchers acting in good faith, in accordance with this policy, will not face legal action from Modehuis or IslandAI. Good faith means: you do not access or modify data belonging to other users, you do not degrade the service for others, and you report findings promptly through the responsible disclosure channel.

6. Threat Model Overview

Seldon's threat model assumes untrusted input payloads and potentially compromised upstream data sources. The enforcement boundary is designed to operate correctly under adversarial input conditions.

In scope:

• Injection via token payloads (schema validation prevents free-form content reaching the PDP).
• Policy bypass attempts (fixed-order rule evaluation with no runtime override).
• Ledger tampering (append-only hash chain with cryptographic binding between records).
• Session hijacking (session-scoped isolation with automatic expiry).

Out of scope:

• Physical access to infrastructure.
• Insider threat at the infrastructure level (database administrator access).

Mitigation approach: Schema-only I/O (no free-form input reaches enforcement logic), deterministic PDP (no runtime override possible), and append-only ledger (no mutation after write).

7. Encryption & Key Management

• In transit: TLS 1.2+ required for all connections. No plaintext transport permitted in production deployments.
• At rest: PostgreSQL transparent data encryption at the host level. Encrypted backups recommended for production.
• Key management: No application-level key management in v0.1. Hash integrity via SHA256 (not encryption). Signing (issuer_signature) reserved for future versions.
• Supply chain: Python dependencies pinned via lock file. Container images use digest-pinned base images.

8. Access Control Model

Access control follows the principle of least privilege across all deployment contexts:

• Playground (public): Anonymous access, pre-computed results only. No database writes, no session state, no user data collection.
• Production deployment: Tenant-scoped access with API key authentication. Role-based authorization: admin (manage policy packs and configuration), operator (run scenarios and view results), auditor (read-only access to ledger and evidence exports).
• Principle: Least privilege. Auditors are read-only. Operators run scenarios but cannot modify policy. Admins manage policy packs but all changes are version-tracked.