🔒 VhyxSeal
GitHub

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

ThreatMitigation
Manifest poisoningHMAC-SHA256 signing — agents reject unsigned or mis-signed manifests
Prompt injection14-pattern injection detection, field length limits, structural trust over textual trust
Fake manifest spoofingDomain binding — manifest is cryptographically tied to its verified domain
Agent impersonationAgent identification policy in AgentPolicy.allowedAgents
Contract replay attacksSingle-use action tokens with 60-second TTL — each token consumed once
Supply chain attacksCore has zero runtime dependencies, GPG-signed releases, two-person release approval
Data exfiltration via conditionsAbstract 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.

// Manifest signing — configured automatically by @vhyxseal/nextjs
// Manual signing API from @vhyxseal/core:
import { signManifest, verifyManifest } from '@vhyxseal/core'

// Sign at build time or request time
const signed = signManifest(manifest, privateKey)
// { signature: "sha256:...", signedAt: "..." }

// Verify before trusting any contract data
const result = verifyManifest(signedManifest, publicKey)
// { valid: true, domain: "example.com", ... }
// On failure: all safety defaults apply — agents cannot act

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.

// Sanitization runs automatically on all string fields
// Zero configuration required — built into defineContract()

import { sanitizeContract } from '@vhyxseal/core'

// Field length limits (enforced, not configurable):
// description:              max 500 characters
// intent:                   max 50 characters
// consequence:              max 300 characters
// condition.description:    max 200 characters

// 14 injection pattern categories detected:
// prompt injection, jailbreak, SSRF, XSS, path traversal,
// SQL injection, code execution, and more

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.

// Action token — auto-generated by @vhyxseal/nextjs for every agent action
// Six-step verification:
//
// 1. Token ID exists in issued map
// 2. Date.now() < token.expiresAt  (60-second window)
// 3. token.contractId === expected.contractId
// 4. token.componentId === expected.componentId
// 5. token.intent === expected.intent
// 6. token.used === false  →  set token.used = true (atomic)
//
// Replay attack: step 6 fails — token already consumed.
// Expired token: step 2 fails — 60-second TTL enforced.

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.

// Domain verification — site must prove ownership
// Verified token issued by VhyxSeal registry after confirmation

import { issueDomainToken, verifyDomainToken } from '@vhyxseal/core'

const { token } = await issueDomainToken("example.com")
// token is stored in manifest as verificationToken

const valid = await verifyDomainToken("example.com", token)
// true if ownership verified, false if not

Layer 5 — Field Length Limits

Hard limits enforced at schema validation level. Not configurable.

FieldLimit
description500 characters
intent50 characters
consequence300 characters
condition.description200 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.