Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.toktra.dev/llms.txt

Use this file to discover all available pages before exploring further.

When an employee leaves your organization, Toktra ensures their access to every LLM tool is revoked immediately — from OpenAI API keys to active agent connections on enrolled devices. This guide covers manual lockout from the dashboard, the automated Okta integration, HRIS-driven offboarding, and reviewing the audit record after the fact.

​
Manual one-click lockout

The Emergency Lockout page lets an admin revoke a user’s LLM access in a single click, without waiting for HRIS or IdP automation.
1

Navigate to Emergency Lockout

Go to Lockout in the sidebar.
2

Find the employee

Locate the user by email in the table. Active employees show a green Active badge.
3

Initiate the lockout

Click Lock Out next to the user’s name.
4

Confirm

A confirmation dialog appears. Click Confirm to proceed. The lockout is irreversible without manual admin intervention.
Triggering a lockout immediately begins the revocation pipeline. The user loses LLM access within seconds. This action is logged and cannot be undone without a deliberate admin override.

​
What happens during a lockout

When a lockout is triggered (manually or automatically), Toktra executes the following steps in order:
1

Provider access revocation

Toktra calls provider admin APIs to revoke the user’s organization membership and any API access tied to their identity (OpenAI, Anthropic, and others connected to your account).
2

Device lock command

A signed lock command is sent to all enrolled devices belonging to the user. Each agent receives the command and immediately blocks outbound LLM connections.
3

Audit snapshot generation

Toktra generates a tamper-proof audit snapshot PDF containing:
  • The user’s identity and lockout timestamp
  • All LLM usage events in the 14-day pre-departure window
  • The revocation confirmation from each provider
  • A chain-of-custody record with RFC 3161 timestamps
4

S3 upload with Object Lock

The audit snapshot PDF is uploaded to the toktra-audit-logs S3 bucket with Object Lock in COMPLIANCE mode and a 7-year retention period. The snapshot cannot be modified or deleted until the retention period expires.

​
Chain of custody

The audit snapshot is backed by a chain-of-custody record — an append-only, tamper-evident audit trail. Each node references its parent, creating an immutable directed acyclic graph. No record can be modified or deleted after it is written. RFC 3161 timestamps from a trusted timestamp authority (DigiCert) provide cryptographic non-repudiation for every entry. This means that even Toktra itself cannot retroactively alter what was recorded at the time of lockout.

​
Reviewing the audit snapshot

After a lockout, you can access the audit snapshot to verify what was captured.
1

Navigate to Legal or HRIS Offboarding

Go to Legal → Legal Holds (LegalHoldPage) or call GET /v1/hris/offboarding/{snapshot_id} via the API.
2

Locate the snapshot

Find the snapshot by user ID or lockout timestamp.
3

Download the PDF

Call GET /v1/hris/offboarding/{snapshot_id}/pdf. The response returns a presigned S3 URL valid for one hour. Download the PDF and verify the RFC 3161 timestamp to confirm the document has not been altered.

​
Okta integration: automatic lockout on deactivation

Toktra integrates with Okta to trigger lockouts automatically when a user is deactivated in your IdP. How it works:
  1. Configure an Okta event hook to send user.lifecycle.deactivate events to the Toktra webhook endpoint provided in Settings → Integrations → Okta.
  2. Toktra receives the webhook, verifies the HMAC-SHA256 signature, and initiates the lockout pipeline for the deactivated user.
  3. The full lockout sequence (provider revocation, device lock commands, audit snapshot) runs automatically.
The Okta webhook fires on user deactivation, not on user deletion. Deactivation is the recommended action in Okta for offboarding, as it preserves the user record in the IdP for audit purposes.
The webhook endpoint URL and signing secret are displayed in Settings → Integrations → Okta after you save the integration. Copy the signing secret into the Okta event hook configuration.

​
HRIS integration: automated detection of terminations

For organizations using Workday or BambooHR, Toktra can automatically detect employee terminations and trigger the offboarding pipeline without any manual dashboard action.

​
Workday

Toktra polls the Workday REST API hourly. When a termination event is detected, the offboarding pipeline starts automatically. Configure the Workday integration at PUT /v1/hris/config: 
{
  "provider": "workday",
  "workday_base_url": "https://wd2-impl-services1.workday.com/ccx/service/your-tenant",
  "workday_username": "integration-user",
  "workday_password": "..."
}

​
BambooHR

Toktra receives termination events from BambooHR via webhook. The endpoint at POST /v1/hris/webhook/bamboohr verifies the X-BambooHR-Signature HMAC-SHA256 header before processing. Configure the BambooHR integration at PUT /v1/hris/config: 
{
  "provider": "bamboohr",
  "bamboohr_subdomain": "yourcompany",
  "bamboohr_api_key": "...",
  "bamboohr_webhook_secret": "..."
}

​
14-day pre-departure anomaly detection

Regardless of whether the lockout is triggered manually, via Okta, or via HRIS, Toktra runs a 14-day pre-departure anomaly detection window before generating the audit snapshot. Toktra analyzes the user’s LLM usage in the 14 days prior to the lockout date and flags:
  • Unusual spikes in token volume
  • Access to models or providers not typically used by the employee
  • Off-hours activity patterns
  • Large data transfers to external LLM endpoints
Anomalies detected in this window are included in the audit snapshot PDF, giving your security team a head start on any investigation.
For high-risk roles (e.g., engineers with access to sensitive codebases), consider using the HRIS integration’s pre-departure detection in combination with the GitHub IP Risk dashboard to correlate anomalous LLM usage with unusual code commit activity.