Security
VhyxSeal sits between AI agents and websites. Security is foundational, not a feature added later. Eight layers are designed from Stage 1. This guide covers the threat model, what is implemented, what is not yet enforced, and how to report vulnerabilities.
Threat Model
What VhyxSeal defends against
| Threat | Mitigation |
|---|---|
| Manifest poisoning | HMAC-SHA256 signing — agents reject unsigned or mis-signed manifests |
| Prompt injection | 14-pattern injection detection, field length limits, structural trust over textual trust |
| Fake manifest spoofing | Domain binding — manifest is cryptographically tied to its verified domain |
| Agent impersonation | Agent identification policy in AgentPolicy.allowedAgents |
| Contract replay attacks | Single-use action tokens with 60-second TTL — each token consumed once |
| Supply chain attacks | Core has zero runtime dependencies, GPG-signed releases, two-person release approval |
| Data exfiltration via conditions | Abstract field references enforced — internal field names never exposed |
What VhyxSeal does NOT defend against
These are out of scope by design. Use appropriate tools for each:
- Consuming application security vulnerabilities (use security audits)
- Server authentication and authorization (use your auth layer)
- Network-level attacks — use HTTPS (TLS at infrastructure level)
- Zero-day vulnerabilities in agent models (beyond scope of contract layer)
What Is Implemented
Layer 1 — HMAC-SHA256 Manifest Signing
Every manifest is cryptographically signed at build time. Agents verify the signature before trusting any contract data. Signature failure triggers maximum safety defaults — agents cannot act. Currently a stub — see Known Limitations below.
Layer 2 — Injection Detection (14 pattern categories)
All string fields in contracts are sanitized before being surfaced to AI agents. Detection runs on 14 pattern categories including prompt injection, jailbreak, SSRF, XSS, path traversal, and SQL injection. Field length limits are hard limits — not suggestions. Structural trust rule: agent safety decisions derive from typed fields (safetyLevel, requiresConfirmation, destructive), never from text description fields alone.
Layer 3 — Action Tokens (6-step verification)
Every agent action generates a single-use token that expires in 60 seconds. Six-step verification is a security decision, not an implementation choice. The order of steps is fixed.
Layer 4 — Domain Verification
Every manifest is cryptographically bound to its verified domain. Agents check manifest domain matches actual domain. Mismatch triggers full manifest rejection.
Layer 5 — Field Length Limits
Hard limits enforced at schema validation level. Not configurable.
| Field | Limit |
|---|---|
| description | 500 characters |
| intent | 50 characters |
| consequence | 300 characters |
| condition.description | 200 characters |
Known Limitations
The following capabilities are defined in this RFC but not yet enforced in 1.0.0-rc.1:
Rate Limit Enforcement
AgentPolicy.rateLimits is schema-defined but not enforced by VhyxSeal middleware in this release. Enforcement implementations are scheduled for 1.1.0.
Current mitigation: implement rate limiting at your infrastructure layer (Vercel, Cloudflare, nginx).
Registry Backend
Domain verification tokens require a trusted registry to be meaningful. A hosted registry is in development. Until then, domain verification provides format validation only.
Security Reporting
We take security vulnerabilities seriously. Please report responsibly — do not create public GitHub issues for security bugs.
Report via: GitHub Security Advisories or security@vhyxara.dev
Acknowledgement: 48 hours
Patch commitment for critical: 14 days
See SECURITY.md on GitHub for the full disclosure policy.