Why Verity?¶

The Problem: Stale Access Is the #1 Identity Attack Vector¶

Every organisation grants access. Few organisations revoke it on time.

The result is access decay — a steady accumulation of permissions that no one uses, no one monitors, and no one revokes until a post-breach forensic report highlights the six-month-old service-account token that an attacker used to move laterally across your cloud estate.

Traditional Identity Governance and Administration (IGA) platforms address this with periodic certification campaigns: once a quarter, managers receive a spreadsheet of entitlements, rubber-stamp "approve all," and move on. The access that should have been revoked survives another 90 days.

timeline
    title Traditional Access Review Cycle
    section Q1 Review
        Jan : Review campaign launched
        Feb : Managers approve 95 % unchanged
        Mar : Campaign closes — stale access persists
    section Gap
        Apr : No visibility
        May : No visibility
        Jun : No visibility — attacker exploits stale SA
    section Q2 Review
        Jul : Next campaign — breach discovered in forensics

How Verity Helps¶

Verity is an Access Decay Intelligence Platform. Instead of periodic campaigns it provides:

The result: stale access is detected within hours, reviewed within days, and remediated before it becomes a breach vector.

The Five Processing Planes¶

Verity processes access data through five distinct planes. Each plane scales independently, communicates via Kafka, and can be deployed as one or more microservices.

graph LR
    subgraph Ingest["① Ingest Plane"]
        direction TB
        C1[Entra ID Connector]
        C2[AWS IAM Connector]
        C3[GitHub Connector]
        C4[Custom Connectors]
    end

    subgraph Normalise["② Normalise Plane"]
        direction TB
        IR[Identity Resolution]
        AC[Asset Classification]
        GR[Graph Builder]
    end

    subgraph Score["③ Score Plane"]
        direction TB
        DE[Decay Engine]
        PM[Peer Model]
        SM[Sensitivity Multiplier]
    end

    subgraph Review["④ Review Plane"]
        direction TB
        RG[Review Generator]
        WF[Workflow Engine]
        NF[Notifications]
    end

    subgraph Remediate["⑤ Remediate Plane"]
        direction TB
        RA[Remediation Actions]
        DR[Dry-Run Validator]
        AL[Audit Logger]
    end

    Ingest -->|Kafka| Normalise -->|Kafka| Score -->|Kafka| Review -->|Kafka| Remediate

    style Ingest fill:#7c4dff,color:#fff,stroke:none
    style Normalise fill:#651fff,color:#fff,stroke:none
    style Score fill:#536dfe,color:#fff,stroke:none
    style Review fill:#448aff,color:#fff,stroke:none
    style Remediate fill:#40c4ff,color:#000,stroke:none

① Ingest Plane¶

Connectors pull audit logs, entitlement snapshots, and identity metadata from upstream systems (Entra ID, AWS IAM, GitHub, Okta, and more). Raw events are published to Kafka with at-least-once delivery guarantees.

② Normalise Plane¶

The Normalise Engine resolves identities across systems (e.g., mapping an AWS IAM role to an Entra ID user), classifies assets by sensitivity, and builds a relationship graph that captures who-has-access-to-what.

③ Score Plane¶

The Decay Engine consumes normalised events and computes a composite decay score (0–100) for every access grant. The scoring model blends six weighted factors — recency, trend, organisational context, peer comparison, review history, and asset sensitivity. Scores are persisted in TimescaleDB as a time-series hypertable.

→ Deep dive: Scoring Model

④ Review Plane¶

When a score crosses a configurable threshold (default: 50), the Review Generator creates a review packet — a self-contained evidence bundle with everything a data owner needs to make an informed keep-or-revoke decision. The Workflow Engine (powered by Temporal) tracks SLAs, sends reminders, and escalates overdue reviews.

→ Deep dive: Review Lifecycle

⑤ Remediate Plane¶

Once a reviewer decides to revoke or reduce access, the Remediation service executes the action through the same connector framework used for ingest. Safety mechanisms include dry-run validation, blast-radius limits, and automatic rollback. Every action is logged immutably to ClickHouse.

→ Deep dive: Remediation Pipeline

Core Components¶

Sources (Connectors)¶

Sources are the adapters that connect Verity to upstream identity and access systems. Each connector implements a standard interface with two capabilities:

1. Read — Pull audit events, entitlements, and metadata during the Ingest phase.
2. Write — Execute remediation actions (revoke, reduce, suspend) during the Remediate phase.

Built-in connectors ship for:

Scoring (Decay Engine)¶

The Decay Engine is the analytical heart of Verity. It receives normalised access events and computes a continuously updated score using six weighted factors.

→ Full details: Scoring Model

Reviews¶

Reviews are the human decision point. Verity generates evidence-rich review packets and routes them to the right person at the right time, tracked by Temporal workflows with SLA enforcement.

→ Full details: Review Lifecycle

Remediation¶

Remediation is the action layer. When a review decision is made — or when a policy triggers automatic action — the Remediation service executes safely through the connector framework.

→ Full details: Remediation Pipeline

Benefits¶

When Not to Use Verity¶

Verity is opinionated software. It excels at continuous access-decay detection and remediation for organisations at scale. It is not the right tool for every situation:

Explore the Documentation¶