SOC 2 Readiness Control Mapping

Internal SOC 2 readiness control mapping for the Grantex Delegated Authorization Platform.

Field	Detail
Prepared by	Grantex maintainers
Readiness snapshot date	February 20, 2026
Publication date	February 28, 2026
Trust Service Categories	Security (CC), Availability (A), Confidentiality (C)
Classification	Public
Report type	Internal readiness control mapping; not a SOC 2 Type I attestation

This page is not an independent CPA attestation and should not be represented as SOC 2 certification. It is a public control mapping intended to help reviewers understand the evidence Grantex maintains while formal audit work is pending.

Readiness Position

This document summarizes controls that map to SOC 2 Security, Availability, and Confidentiality criteria. It does not express an auditor opinion on control design or operating effectiveness.

System Description

Grantex provides a Delegated Authorization Platform — an open, model-neutral protocol for AI agents acting on behalf of human users. The System enables developers to register AI agents, obtain human-consented authorization grants, issue cryptographically signed grant tokens (RS256 JWTs), revoke grants in real time, and maintain a tamper-evident audit trail.

Infrastructure

Component	Technology	Role
Authorization service	Node.js (Fastify v5)	HTTP API
Database	PostgreSQL 16	Persistent store
Cache	Redis 7	Revocation lookups, session nonces
CI/CD	GitHub Actions	Testing, CodeQL, dependency review

Data Categories

Category	Sensitivity
Developer API keys	High (SHA-256 hashes only)
Grant tokens	High (not stored post-issuance)
Grant records	Medium
Audit log entries	Medium
SCIM user data	Medium
SSO credentials	High (encrypted at rest)

Key Controls

Security (CC6)

• API key hashing — SHA-256 hashes only; plaintext never stored
• Bearer token auth — Every endpoint validates via authPlugin preHandler
• Redirect URI pre-registration — Exact-match validation
• SCIM credential isolation — Separate token infrastructure
• RS256 algorithm pinning — Hardcoded in all three verification layers
• Minimum 2048-bit RSA keys — Enforced at startup
• Real-time grant revocation — Immediate Redis + database propagation
• Cascade revocation — Atomic recursive CTE
• JTI replay prevention — Redis O(1) lookup with database fallback

Availability (A1)

• Health check endpoint — GET /health for load balancers
• Redis-backed revocation — O(1) hot path, database fallback
• Stateless service design — Horizontal scaling without data sync
• Container-based deployment — Docker Compose with depends_on ordering

Confidentiality (C1)

• API key non-persistence — Returned once at creation, never stored
• Developer-scoped data isolation — All queries filtered by developer_id
• Grant token non-storage — JWTs not persisted, only metadata
• Redis TTL-based expiry — Automatic cleanup of revocation records

Monitoring Controls

• Anomaly detection — Five anomaly types, four severity levels
• Hash-chain integrity verification — Compliance endpoint validates audit chain
• 174 automated tests — Run on every CI pipeline execution
• CodeQL static analysis — Security and quality queries on every push
• Dependency review — Blocks high-severity CVEs and prohibited licences

Complementary User Entity Controls

1. Developers must store API keys securely and rotate if compromised
2. Developers must supply accurate principalId values
3. Developers must register only legitimate redirect URIs
4. Developers must review anomaly alerts and audit exports
5. Self-hosted deployments require developer-managed network controls

Findings Summary

The readiness mapping tracks findings from the referenced third-party security assessment. Open findings must be treated as remediation work, not as exceptions approved by a SOC 2 auditor.

---

This public readiness mapping is maintained at github.com/mishrasanjeev/grantex/blob/main/docs/soc2-type1/report.md.