FAQ¶

Answers to the most common questions about Verity. Can't find what you're looking for? Open a discussion on GitHub.

General¶

What is access decay?¶

Access decay is the gradual increase in risk that occurs when an access grant remains in place but is no longer actively needed. Think of it like food expiry — a permission that was perfectly valid six months ago may now be a liability if the person hasn't used it, has changed roles, or has left the organisation.

Verity quantifies this decay as a score from 0 (fresh / actively used) to 100 (fully decayed / high risk).

How is Verity different from PAM (Privileged Access Management)?¶

PAM tools focus on securing and vaulting privileged credentials — SSH keys, admin passwords, service-account tokens. Verity operates at a different layer: it analyses all access grants (not just privileged ones) across identity providers and data platforms, scores how stale each grant has become, and orchestrates reviews and remediation.

Verity complements PAM — it identifies which privileged accounts are decayed, so your PAM tool can enforce tighter controls on the right accounts.

What connectors are supported?¶

Verity v1.0 ships with six connectors:

Scoring¶

How does the decay scoring work?¶

The Decay Engine evaluates six weighted factors for every access grant:

1. Days since last use — How long since the principal actually exercised this permission?
2. Peer comparison — Do peers in the same department/role have similar access?
3. Privilege level — Higher privileges (admin, write) decay faster than read-only.
4. Asset sensitivity — Access to a sensitivity-5 database scores higher than a dev sandbox.
5. Login frequency — Has the principal logged in to the source system recently?
6. HR signals — Has the principal changed roles, gone on leave, or been terminated?

Each factor produces a sub-score; these are combined using configurable weights into the final 0–100 decay score.

How often are scores recalculated?¶

By default, every 6 hours. The schedule is configurable per connector and globally:

# config/scoring.yaml
scoring:
  schedule: "0 */6 * * *"   # Every 6 hours (cron syntax)
  batch_size: 5000           # Grants processed per batch

How does Verity handle false positives?¶

Verity uses several mechanisms to minimise false positives:

• Multi-factor scoring — A single factor (e.g., no recent login) alone won't push a score to Critical. Multiple signals must converge.
• Peer comparison — If everyone in the role has the same access, the score stays low even if individual usage is infrequent.
• Configurable thresholds — Adjust the score thresholds that trigger reviews to match your organisation's risk appetite.
• Dry-run mode — Run remediation in dry-run for weeks before enabling live revocation.
• Reviewer override — Data owners can approve grants they know are still needed, resetting the review clock.

Connectors & Integration¶

Can I write custom connectors?¶

Yes. Verity provides a Connector SDK that defines the interface every connector must implement:

from verity.sdk.connector import BaseConnector, ConnectorResult

class MyCustomConnector(BaseConnector):
    """Pull grants from a custom system."""

    async def fetch_principals(self) -> list[Principal]:
        ...

    async def fetch_assets(self) -> list[Asset]:
        ...

    async def fetch_grants(self) -> list[Grant]:
        ...

    async def revoke_grant(self, grant_id: str) -> ConnectorResult:
        ...

See the Connector SDK guide for the full development workflow.

Can Verity integrate with ServiceNow or Jira?¶

Yes. The Remediation Executor supports pluggable action handlers. Instead of (or in addition to) revoking access directly, it can open a ticket in an external ITSM system:

# config/remediation.yaml
remediation:
  actions:
    - type: revoke        # Direct revocation via connector
    - type: ticket         # Open ITSM ticket
      provider: servicenow
      config:
        instance: mycompany.service-now.com
        assignment_group: "IAM Operations"

Jira integration works the same way by setting provider: jira.

Infrastructure & Deployment¶

What databases are required?¶

Verity requires four data-infrastructure components:

Additionally, Temporal is required for durable workflow orchestration.

What's the minimum infrastructure?¶

For a development / evaluation environment:

For production (up to 100k grants):

Can I use Verity without Kubernetes?¶

Yes. Verity ships with a Docker Compose configuration for local development and small-scale production deployments:

docker compose up -d

For production without Kubernetes, you can run the containers on any Docker-capable host(s) using Docker Compose or a similar orchestrator (e.g., Nomad, ECS).

Is there a SaaS version?¶

Not yet. Verity v1.0 is a self-hosted platform. A managed SaaS offering is on the roadmap — follow the GitHub repository for announcements.

Operations¶

What's the performance like?¶

Benchmark numbers on the recommended production infrastructure:

Performance scales linearly by adding Decay Engine and Ingest Worker replicas.

How do I monitor Verity?¶

Every Verity microservice exposes:

• /healthz — liveness probe (HTTP 200 / 503)
• /readyz — readiness probe (HTTP 200 / 503)
• /metrics — Prometheus-compatible metrics

Pre-built Grafana dashboards are included in the Helm chart:

• Ingest throughput & error rates
• Scoring latency & queue depth
• Review SLA compliance
• Remediation success/failure rates
• Kafka consumer lag

See Monitoring & Alerting for setup instructions.

How is data secured?¶

See Security Model for the full security architecture.

Reviews & Remediation¶

What happens if a review times out?¶

When a review exceeds its SLA, the Workflow Engine (Temporal) triggers the configured escalation chain:

flowchart LR
    A["Review Created"] --> B["Assigned to<br/>Data Owner"]
    B -->|SLA expires| C["Escalate to<br/>Manager"]
    C -->|SLA expires| D["Escalate to<br/>Security Team"]
    D -->|SLA expires| E["Auto-Remediate<br/>(if configured)"]

    style E fill:#f44336,color:#fff,stroke:none

Default escalation SLAs:

Can I customise review routing rules?¶

Yes. Review routing is configured via policy rules:

# config/review-policies.yaml
policies:
  - name: financial-systems
    match:
      asset_sensitivity: [4, 5]
      asset_tags: ["financial"]
    routing:
      primary: asset_owner
      escalation:
        - role: manager
          after: 7d
        - role: security_team
          after: 10d
    thresholds:
      review: 50       # Score ≥ 50 → generate review
      auto_remediate: 90  # Score ≥ 90 → skip review, auto-revoke

Troubleshooting¶

Where can I find logs?¶

All services emit structured JSON logs with correlation IDs. In Kubernetes:

# All Verity services
kubectl logs -n verity -l app.kubernetes.io/part-of=verity --tail=100

# Specific service
kubectl logs -n verity -l app.kubernetes.io/name=decay-engine --tail=100

See Troubleshooting for common issues and resolution steps.