> ## Documentation Index
> Fetch the complete documentation index at: https://docs.grantex.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 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 |

<Warning>
  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.
</Warning>

## 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](https://github.com/mishrasanjeev/grantex/blob/main/docs/soc2-type1/report.md).*