Platform Reference

CoreLink operates a per-tenant SSH Certificate Authority as well as a full X.509 PKI hierarchy for TLS. When a user connects to a session target, the system generates an ephemeral Ed25519 key pair, signs it with the tenant CA, and provisions the certificate with configurable extensions (port forwarding, agent forwarding, PTY allocation). X.509 certificates support the full ACME protocol for automated issuance and renewal.

Constrained CAs use RFC 5280 X.509 Name Constraints to bind an intermediate CA to a specific DNS suffix, IP range, or email domain -- delegating issuance authority without risk of overreach. The CA private key is stored encrypted in your KMS or HSM, ensuring it never exists in plaintext outside the device boundary. OCSP responder and CRL distribution points are hosted automatically for revocation checking.

Key Configuration

• CA key algorithm (Ed25519 for SSH, RSA-2048/4096 or EC P-256/P-384 for X.509)
• Certificate validity duration
• Allowed SSH extensions (port forwarding, agent forwarding, PTY allocation)
• X.509 Name Constraints (DNS, IP, email)
• OCSP responder URL and CRL distribution point
• Principal mapping rules

CoreLink vends short-lived AWS, Azure, and GCP credentials on demand through provider-native APIs (AWS STS AssumeRole, Azure AD OIDC federation, GCP Workload Identity Federation). Each credential bundle is issued to a specific NHI or user, scoped to the requested role or service account, and expires automatically when the lease ends.

Leases can be revoked immediately if the consuming workload is decommissioned or compromised. Full issuance and revocation history is captured in the audit log with actor, scope, and reason.

Key Configuration

• Cloud provider (AWS, Azure, GCP)
• Default lease duration
• Role / service account allowlist
• Revocation webhook endpoint

Config Files store entire application configuration artifacts -- YAML, JSON, TOML, properties, or arbitrary text -- alongside the secrets they reference. Each file is encrypted at rest with the workspace KEK, versioned on every save, and retrievable via API, CLI, or SDK. Embedded secret references ({{secret.name}}) are resolved at retrieval time so the deployed file always contains the current rotated values.

Version history keeps every prior revision with diff view, and rollback restores a previous version as a new head. Files are scoped to workspace and environment so a single template can be deployed with environment-specific substitutions.

Key Configuration

• File format (YAML, JSON, TOML, properties, raw)
• Embedded secret reference syntax
• Version retention policy
• Environment-specific overrides

Extend rotation to any target not covered by built-in engines. Each secret can have three associated shell scripts: rotate (generates new credential and applies it to the target system), verify (confirms the new credential is accepted), and rollback (reverts to the previous value if verify fails).

Scripts execute in a sandboxed environment with a 60-second timeout, restricted PATH, and no network access beyond explicitly allowed endpoints. Environment variables expose the current and previous secret values securely.

Key Configuration

• Script paths (rotate / verify / rollback)
• Execution timeout
• Allowed outbound endpoints
• Environment variable allowlist

Instead of storing long-lived database passwords, CoreLink generates short-lived credentials on demand. Each credential set is scoped to a specific database connection and automatically expires after the configured TTL. The system handles credential rotation transparently, cycling passwords without service interruption.

Supported engines include PostgreSQL, MySQL, and MongoDB. Each connection stores its configuration encrypted at rest using the same envelope encryption as secrets.

Key Configuration

• Database engine selection (PostgreSQL, MySQL, MongoDB)
• Credential TTL
• Max concurrent leases
• Rotation schedule

CoreLink supports PKCS#11 v2.40-compatible HSMs for storing CA private keys and KMS master keys. Tested with SafeNet Luna and Thales Luna Network HSM. The PKCS#11 provider is configured per-tenant; key generation and cryptographic operations execute inside the HSM boundary -- private key material never leaves the device.

HSM slots are addressed by label, and PIN authentication is handled via environment-injected secrets.

Key Configuration

• PKCS#11 library path
• Slot label
• PIN source (env var reference)
• Supported key algorithms (RSA-2048/4096, EC P-256/P-384)

A lightweight Kubernetes operator (~5.5MB binary) syncs CoreLink secrets into native Kubernetes Secret objects so existing workloads consume them with no code changes. Declare a SecretSync custom resource that references a CoreLink secret name and target namespace, and the operator maintains the Kubernetes Secret up-to-date on every rotation.

The operator authenticates to CoreLink via NHI passwordless attestation using the pod's service account token. No long-lived tokens, no sidecar injection, no mutating webhooks.

Key Configuration

• SecretSync refresh interval
• Target namespaces allowlist
• NHI ID for operator authentication
• Sync failure alert channel

SSH and RDP sessions are brokered through CoreLink with full recording and command-level policy enforcement. Users never receive direct credentials -- instead, they request JIT access, which provisions ephemeral certificates (SSH) or temporary AD accounts (RDP).

Every keystroke is recorded in TTYRec format and stored gzip-compressed. The command interceptor buffers terminal input and checks each command against the target's policy before forwarding. Eight built-in preset groups cover common restriction scenarios, and custom block rules can target specific commands or patterns.

Key Configuration

• Recording retention period
• Command policy presets (8 built-in groups)
• Session idle timeout
• Concurrent session limit

CoreLink ships with rotation providers for the most common credential types: LDAP (Active Directory unicodePwd over LDAPS), PostgreSQL rootless rotation (GRANT-based pattern using a low-privilege rotation account), MySQL, MongoDB, SSH keys, and RDP credential injection (delivered as a downloadable .rdp file rather than a copy-paste password).

Infrastructure credential rotation supports zero-disruption handover -- CoreLink provisions a new credential, validates it, updates dependent systems, and retires the old credential only after a configurable overlap window. Rotation policy templates allow the same rotation cadence, retry logic, and notification settings to be applied to hundreds of secrets without duplication.

Key Configuration

• Provider selection (LDAP, PostgreSQL, MySQL, MongoDB, SSH, RDP)
• Dual-credential overlap window (seconds)
• Rotation policy template reference
• Retry count and backoff on failure

CoreLink encrypts every secret with AES-256-GCM using a unique data encryption key (DEK) per secret. The DEK is then wrapped by a key encryption key (KEK) stored in your KMS provider of choice -- AWS KMS, Azure Key Vault, GCP Cloud KMS, or HashiCorp Vault. Version history tracks every change, and soft-delete with configurable retention keeps secrets recoverable.

Secrets can be organized by workspace and environment, with RBAC controlling who can read, write, or admin each scope. Bulk import via JSON or CSV makes migration from existing tools straightforward.

Key Configuration

• KMS provider selection (AWS KMS, Azure Key Vault, GCP Cloud KMS, HashiCorp Vault)
• Default rotation interval
• Version retention policy
• Bulk import format (JSON/CSV)

Session groups bundle related session targets (SSH, RDP, database) so policies, approvers, and command restrictions are defined once and applied to every member. Add a new target to the group and it immediately inherits the group's policy. Group-level approvers can delegate individual request handling while a tenant administrator owns the group definition.

Groups make bulk onboarding practical -- a Kubernetes cluster with 40 nodes, or a database fleet with dozens of replicas, can be managed as a single access surface.

Key Configuration

• Group-level command policy preset
• Group approver chain
• Default session recording behavior
• Target auto-assignment rules (by tag, CIDR)

CoreLink scans external domains and internal IP ranges to automatically discover deployed TLS certificates. Each certificate is fingerprinted by serial number, subject, issuer, SANs, and expiry date. Discovered certs appear in the Certificate Inventory alongside secrets-vault-managed certs, giving operators a unified view.

Scheduled rescans detect newly deployed certs and flag those approaching expiry or using deprecated cipher suites.

Key Configuration

• Scan targets (CIDR ranges / domain lists)
• Scan interval
• Expiry warning threshold (days)
• Alert channels for approaching expiry

The Transit engine provides encryption-as-a-service so applications never need to hold key material. Supported operations include encrypt, decrypt, sign, verify, hmac, and rewrap. Each key is versioned; decrypting a ciphertext written under an old version transparently succeeds while new ciphertext is always produced with the latest version.

Key rotation generates a new version without re-encrypting historical data. Rewrap is available to migrate ciphertext forward in bulk when needed. Supported key types include AES-256-GCM, ChaCha20-Poly1305, RSA-2048/4096, and Ed25519.

Key Configuration

• Key type (symmetric, signing, HMAC)
• Rotation schedule per key
• Allowed operations per role
• Minimum key version for decrypt

The transparent session client is a user-space TCP proxy that intercepts outbound connections to configured targets and routes them through the CoreLink session broker. Users run their normal ssh, psql, or mongosh commands unchanged -- the proxy transparently obtains JIT approval, injects ephemeral credentials, and tees the session to the recording pipeline.

No TUN/TAP interface, no kernel extension, no root privileges required. The client reads a simple TOML config file listing which host:port tuples should be intercepted and presents a system tray UI for approval prompts.

Key Configuration

• Interception rules (host, port, protocol)
• Local listener address
• Approval prompt style (tray, CLI, browser)
• Fallback behavior when broker unreachable

CoreLink provides bidirectional Active Directory integration for managing users, groups, and organizational units. Connections are established via LDAPS with configurable bind credentials, and sync operations can be triggered manually or scheduled on an interval.

AD accounts created through CoreLink for RDP session brokering are automatically provisioned with random passwords and cleaned up after session expiration. Group membership changes flow in both directions, keeping CoreLink permissions aligned with your directory.

Key Configuration

• LDAPS connection string
• Sync interval
• OU filter scope
• Account cleanup policy

The Connectors Hub provides native integrations with 50+ upstream systems organized by category: Identity Providers (Okta, Auth0, Azure AD, Ping), HRIS (Workday, BambooHR, SAP SuccessFactors), ITSM (ServiceNow, Atlassian Jira, Zendesk), Collaboration (Slack, Microsoft Teams), Dev Tools (GitHub Org, GitLab, Bitbucket), Cloud (AWS IAM, Azure AD, GCP IAM), and SCIM 2.0 for any SCIM-compatible provider.

Each connector maps upstream attributes to CoreLink user fields and group memberships. When an employee is terminated in Workday, their CoreLink access is revoked within the sync interval; when they change departments, group memberships update automatically. Conflict resolution rules handle cases where multiple sources assert different values for the same attribute, and sync history is captured in the audit log.

Key Configuration

• Connector type (50+ options across IDP, HR, ITSM, Cloud, Dev, Collaboration)
• Sync schedule (interval, webhook-driven, manual)
• Attribute mapping and transformation rules
• Conflict resolution strategy (upstream wins, most recent, manual)

Endpoint Privilege Management evaluates device posture signals before granting access to privileged resources. The EPM agent (or integration with CrowdStrike / SentinelOne) reports OS patch level, full-disk encryption status, EDR agent presence, and certificate trust chain integrity. Posture results are cached with a configurable TTL and evaluated at session initiation and secret access.

Policies define minimum posture requirements per workspace or session target. Non-compliant devices receive a remediation prompt with specific instructions rather than a generic denial.

Key Configuration

• Posture check TTL (minutes)
• Required OS patch age (days)
• EDR vendor allowlist (CrowdStrike, SentinelOne)
• Remediation redirect URL

CoreLink issues SPIFFE-compatible identities for workloads -- both X.509-SVIDs (certificates) and JWT-SVIDs -- using the standard SPIFFE ID format (spiffe://tenant/namespace/workload). Trust bundle endpoints are exposed automatically so federated trust domains can validate each other's identities.

NHI federation bindings link a CoreLink workload identity to an external trust domain (another CoreLink tenant, a SPIRE deployment, or any SPIFFE-compliant issuer). Cross-domain authentication works without shared secrets or pre-provisioned credentials.

Key Configuration

• Trust domain name
• Federation binding targets
• Trust bundle refresh interval
• JWT-SVID default audience and lifetime

The identity graph correlates user records across Active Directory, Okta, Workday, and CoreLink local accounts into a unified view. Each person is represented as a single node regardless of how many upstream accounts they have. The graph detects orphaned accounts (upstream record deleted but local access remains), duplicate identities (same person with multiple unlinked accounts), and missing ownership for service accounts.

Graph updates run on the same schedule as connector syncs and produce a correlation confidence score for each link.

Key Configuration

• Correlation attributes (email, employee ID, UPN)
• Minimum confidence threshold for auto-linking
• Manual review queue for low-confidence matches
• Orphan notification recipients

Tenant administrators can configure external identity providers for SSO. CoreLink supports OIDC, SAML 2.0, and LDAP federation. Each tenant can have a single active IdP configuration with custom claim-to-role mapping.

When a user authenticates through the external IdP, CoreLink provisions or updates their local account, syncs group memberships from IdP claims, and establishes a session with the appropriate RBAC permissions.

Key Configuration

• Protocol (OIDC, SAML 2.0, LDAP)
• Issuer URL and client credentials
• Claim mapping rules
• Group sync behavior

CoreLink supports multiple MFA factor types per user: TOTP (Google Authenticator, 1Password, Authy), WebAuthn/passkeys for phishing-resistant hardware and platform authenticators, backup codes for recovery, and Email or SMS OTP as fallback factors. Users can register multiple factors and choose which to present at login.

Tenant administrators configure MFA enforcement policy -- required for all users, required for privileged roles only, or required at step-up checkpoints (accessing production secrets, approving JIT access, administering tenants). Policies integrate with the session broker so step-up challenges gate access to high-sensitivity session targets.

Key Configuration

• Allowed factor types (TOTP, WebAuthn, Email OTP, SMS OTP)
• Enforcement policy (always, privileged-only, step-up checkpoints)
• Backup code generation policy
• Session re-verification interval

The Non-Human Identity registry catalogs every service account, API key, machine credential, and CI/CD token across your organization. Each NHI entry tracks the owning team, creation date, last-used timestamp, expiration policy, and an automatically calculated risk score based on privilege level, age, and usage patterns.

Orphaned NHIs -- credentials with no active owner or no recent usage -- are flagged for review. The registry integrates with access review campaigns so NHIs are recertified alongside human identities.

Key Configuration

• NHI discovery sources (AD service accounts, API keys, CI tokens)
• Ownership assignment rules
• Orphan detection threshold (days since last use)
• Risk score weights

CoreLink acts as a full OAuth2 and OpenID Connect identity provider for external applications. Register OAuth client applications, issue authorization codes and access tokens, and expose standard discovery endpoints: /.well-known/openid-configuration, JWKS, UserInfo, and token revocation. Supported grants include authorization code with PKCE, client credentials, refresh token, and device authorization.

Downstream systems -- AWS STS, Azure AD Workload Identity Federation, GCP STS, or any OIDC-aware app -- federate directly to CoreLink without needing a separate IdP. Consent screens, scope-based permissions, and per-client token lifetimes are fully configurable.

Key Configuration

• Client application registration (name, redirect URIs, allowed grants)
• Scope definitions and consent requirements
• Access token and refresh token lifetime
• Signing algorithm (RS256, ES256, EdDSA)

Privilege Discovery scans cloud accounts, directories, and target infrastructure to inventory who has access to what. Each discovered privilege is classified by sensitivity (read, write, admin, secrets-bearing) and assigned a 0-100 risk score reflecting blast radius, recency of use, and exposure to the public internet.

BFS traversal of the identity graph surfaces escalation paths -- for example, a support user who can assume a role that manages production IAM. Findings feed directly into access review campaigns and role mining suggestions.

Key Configuration

• Scan targets (cloud accounts, directories, session targets)
• Scan interval (daily, weekly, on-demand)
• Risk score weights (blast radius, staleness, exposure)
• Escalation path depth limit

Provider Sync pushes secrets from CoreLink to external secret stores -- AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager. When a secret is created or rotated in CoreLink, the change propagates to configured providers within the sync interval. This enables teams to adopt CoreLink as the authoritative source while consuming secrets through their existing cloud-native tooling.

Sync status is tracked per secret per provider, with automatic retry on transient failures and alerting on persistent sync errors.

Key Configuration

• Target providers (AWS, Azure, GCP)
• Sync interval
• Secret filter (by workspace, tag, or name pattern)
• Failure alerting threshold

Governance teams can launch periodic access review campaigns that require designated reviewers to certify or revoke user entitlements. Campaigns can target specific workspaces, groups, or resource types, and operate on configurable schedules (quarterly, semi-annually, annually).

Each review generates an audit trail documenting every certification decision. SLA tracking ensures reviews complete on time, with escalation notifications for overdue items.

Key Configuration

• Review frequency (quarterly, semi-annually, annually)
• Reviewer assignment rules
• SLA duration
• Escalation chain

The approval engine powers JIT access workflows. When a user requests access to a privileged resource, the request is routed to one or more approvers. Multi-level approval chains support scenarios where both a team lead and security team must sign off.

Approved access is time-bound with automatic expiration. The system tracks approval history, denial reasons, and time-to-approve metrics for governance reporting.

Key Configuration

• Approval chain depth
• Time-bound grant duration
• Auto-expiration rules
• Approval delegation

Automated deprovisioning removes access when an employee leaves the organization or changes roles. When Workday or Okta signals a termination event, CoreLink executes a configurable workflow: revoke all secret access, terminate active sessions, disable AD accounts, remove group memberships, and expire pending approvals. The entire sequence is logged as a single correlated audit event.

Partial deprovisioning handles role changes (movers) by revoking access that is no longer appropriate while preserving entitlements that carry over to the new role.

Key Configuration

• Trigger sources (Workday, Okta, manual)
• Workflow steps (revoke, disable, notify)
• Grace period before final deletion
• Mover detection rules

Groups provide a layer of indirection between users and permissions. Instead of granting access to individual users, administrators assign permissions to groups and then add users (or other groups) as members. CoreLink groups support workspace-scoped permission rules, nested group membership, and bidirectional sync with Active Directory groups.

Group membership changes are audited and can trigger micro certifications when new members are added to sensitive groups.

Key Configuration

• Group type (static, dynamic rule-based)
• AD sync mapping
• Nested group depth limit
• Sensitive group flag (triggers micro-cert on membership change)

Micro certifications are event-driven recertification checks triggered by access pattern changes rather than calendar schedules. When a user receives new entitlements, changes roles, or accesses a resource for the first time, a targeted certification is created for the relevant reviewer. This supplements periodic access reviews with continuous, just-in-time validation.

Each micro certification includes the triggering event, the entitlement in question, and a one-click approve/revoke interface.

Key Configuration

• Trigger events (role change, new entitlement, first access)
• Reviewer assignment rules
• Auto-expire if not reviewed (days)
• Notification channels

CoreLink uses a direct resource:action grant model. Permissions are assigned to users or groups and scoped to a specific workspace (or tenant-wide for administrative actions). Each grant specifies a resource type (secrets, sessions, groups, audit, etc.) and an action (read, write, admin, approve). The RBAC engine evaluates grants as a triple: (subject, action, resource).

Permission grants support expiration dates for time-limited access and can be filtered by environment within a workspace.

Key Configuration

• Grant scope (workspace, tenant-wide)
• Resource types and actions
• Expiration policy
• Environment filter

The policy engine evaluates access requests against declarative rules in real time. Policies can enforce time-of-day restrictions, geo-fencing (allow access only from specific countries or IP ranges), minimum approval depth, and conditional requirements (e.g., require MFA step-up for production workspaces). Policies are versioned and auditable -- every change is tracked in the audit log.

Policy simulation mode lets administrators test proposed policies against historical access data before activating them in enforcement mode.

Key Configuration

• Policy type (time, geo, approval, conditional)
• Scope (tenant-wide, workspace, resource type)
• Enforcement mode (enforce / simulate / audit-only)
• Policy priority and conflict resolution

Role mining analyzes actual access patterns across your organization to discover implicit roles. The algorithm clusters users with similar entitlement profiles, suggests role definitions that would cover each cluster with least privilege, and estimates the number of individual grants that would be eliminated by adopting the proposed roles.

Impact simulation shows what would change if a proposed role were activated -- which users would gain or lose access, and whether any SoD policies would be violated.

Key Configuration

• Minimum cluster size for role suggestion
• Entitlement similarity threshold
• Excluded accounts (service accounts, break-glass)
• Analysis window (days of access history)

End users access a guided wizard interface to request access to secrets, session targets, and AD resources without contacting an administrator. The portal presents available resources based on the user's current permissions and workspace membership.

Requests flow through the approval engine, which routes them to the appropriate approver based on configurable rules. Users can track request status and receive notifications when access is granted or denied.

Key Configuration

• Available request types
• Auto-approval rules
• Request expiration
• Notification channels

Segregation of Duties policies define conflicting role combinations that no single user should hold simultaneously. CoreLink ships with 20 built-in SoD templates covering common conflicts (e.g., "cannot hold both Secrets Admin and Audit Admin"). Custom policies can be defined by specifying role pairs and the conflict severity (block or warn).

The SimulateGrant API evaluates every proposed access grant against active SoD policies before the grant is persisted, preventing violations at the source rather than detecting them after the fact.

Key Configuration

• Policy template selection (20 built-in templates)
• Custom role pair definitions
• Conflict severity (block / warn)
• Exception approval workflow

Workspaces provide hierarchical isolation for multi-team organizations. Each workspace contains its own environments (development, staging, production), and secrets are scoped to a workspace-environment pair. Users can belong to multiple workspaces with different permission levels in each.

Workspace administrators manage their own users and groups without affecting other workspaces. Cross-workspace access requires explicit grants from both workspace administrators.

Key Configuration

• Environment naming convention
• Default workspace permissions
• Cross-workspace sharing policy
• Workspace quota limits

Every action in CoreLink generates an audit event with full user attribution, timestamp, resource details, and a SHA-256 hash linking it to the previous event. This hash chain makes the audit log tamper-evident -- any modification to a historical event breaks the chain.

Over 139 distinct event types cover secrets access, session activity, configuration changes, approval decisions, and administrative actions. Audit logs can be filtered, searched, and exported for external SIEM integration.

Key Configuration

• Log retention period
• Hash chain verification schedule
• Export format (JSON/CSV)
• SIEM integration endpoint

Break-glass accounts hold sealed emergency credentials that require an N-of-M quorum of designated approvers to unseal. Each unseal request is tracked as a first-class audit event, broadcast to the compliance event topic, and delivered to the configured SIEM for real-time alerting. SHA-256 unseal codes are issued to each approver individually -- the credential is only revealed when enough codes are combined.

Unsealed accounts auto-reseal after a configurable TTL so emergency access cannot be left open. The full lifecycle (seal, unseal request, vote, reveal, reseal) is captured in a hash-chained audit record suitable for SOC 2, HIPAA, and PCI-DSS evidence.

Key Configuration

• Required approver count (N-of-M quorum)
• Auto-reseal TTL (hours)
• SIEM alert destination
• Approver rotation policy

CoreLink generates compliance reports mapped to SOC 2, HIPAA, and PCI-DSS control frameworks. Reports aggregate evidence from audit logs, access reviews, encryption status, and rotation compliance into a single exportable package.

Reports can be generated on demand or scheduled to run automatically. Each report includes a summary dashboard, detailed findings, and remediation recommendations for any gaps identified.

Key Configuration

• Report schedule (weekly, monthly, quarterly)
• Target frameworks (SOC 2, HIPAA, PCI-DSS)
• Distribution list
• Evidence retention period

Data residency policies pin tenant secrets, recordings, and audit events to a specific geographic region (US, EU, APAC, or customer-specified). KMS keys are provisioned in-region, storage buckets are locked to the region, and cross-region replication is disabled. Requests originating outside the allowed region can be blocked (enforce mode) or logged for investigation (audit mode).

Violations -- an access attempt from a disallowed region, or a storage operation that would write data out of region -- are tracked in a dedicated residency violations log and surface on the compliance dashboard. Each tenant can have independent residency settings.

Key Configuration

• Allowed regions (US, EU, APAC, custom)
• Enforcement mode (enforce, audit)
• Per-workspace residency override
• Violation alert recipients

Pre-built control mappings translate CoreLink's security capabilities to specific compliance framework requirements. The gap analysis dashboard shows which controls are fully satisfied, partially met, or missing, with actionable remediation guidance for each gap.

Supported frameworks include SOC 2 Type II, HIPAA Security Rule, PCI-DSS v4.0, and ISO 27001. Custom frameworks can be defined by mapping controls to CoreLink evidence sources.

Key Configuration

• Active frameworks (SOC 2 Type II, HIPAA, PCI-DSS v4.0, ISO 27001)
• Custom control definitions
• Gap remediation owners
• Dashboard refresh interval

Identity Security Posture Management (ISPM) produces a 0-100 score for each workspace and a roll-up tenant score. Five risk categories contribute: dormant accounts (no login in N days), orphaned NHIs (service accounts with no owner), SoD violations (users with conflicting role pairs), stale credentials (secrets past rotation window), and open access review items.

Each category has a configurable weight. The score updates daily and is visible on the compliance dashboard alongside trend history.

Key Configuration

• Category weights (0-100 per category, normalized)
• Dormant account threshold (days)
• SoD violation rule sets
• Score refresh schedule

When a SoD violation is detected -- either through SimulateGrant blocking a new grant or through a periodic scan of existing entitlements -- a remediation record is created. Each record tracks the conflicting roles, the affected user, the detection method, the remediation action taken (revoke, reassign, or exception grant), and who approved the resolution.

The remediation log provides auditors with a complete history of SoD violation handling, including before/after permission states. Exportable in PDF and CSV for SOC 2 and ISO 27001 evidence packages.

Key Configuration

• Auto-remediation rules (revoke lower-privilege role)
• Exception grant approval chain
• Exception expiration duration
• Export format (PDF / CSV)

Real-time monitoring detects policy violations as they occur -- unauthorized access attempts, expired credential usage, failed rotation cycles, and compliance drift. Alerts are triggered based on configurable thresholds and severity levels.

Notification channels include email, webhook, and in-app alerts. Escalation rules ensure critical violations reach the appropriate team even outside business hours.

Key Configuration

• Alert severity thresholds
• Notification channels (email, webhook, in-app)
• Escalation rules
• Suppression windows

Device posture checks are evaluated at session initiation and can gate access to privileged sessions and high-sensitivity secrets. The posture agent (installed on the client endpoint) reports: OS version and patch level, full-disk encryption status, EDR agent presence and last check-in time, and certificate trust chain validation.

Posture results are cached with a configurable TTL. Policies define minimum requirements per workspace or session target; users on non-compliant devices receive a remediation prompt rather than an access denial.

Key Configuration

• Posture agent endpoint
• Check TTL (minutes)
• Required OS patch age (days)
• EDR vendor allowlist
• Remediation redirect URL

The Transit Agent connects to GitHub, GitLab, and Bitbucket repositories and scans commit history and working tree files for exposed credentials. Detection patterns cover API keys, connection strings, private keys, and certificates across 40+ service-specific formats.

When a match is found, the Transit Agent reports it to CoreLink, which creates a finding with repository path, commit SHA, line number, and matched pattern type. Findings can trigger automatic secret rotation if a matching secret exists in the vault.

Key Configuration

• SCM platform and authentication token
• Repository include / exclude patterns
• Scan on push vs. scheduled
• Pattern set selection
• Auto-rotate on confirmed match

CoreLink forwards audit events to external SIEM platforms using syslog (RFC 5424) and CEF (Common Event Format). Supported output modes: UDP syslog, TCP syslog with TLS, and HTTP webhook. Multiple endpoints can be configured simultaneously with independent format settings.

Events are tagged with facility and severity per RFC 5424 and include the full CoreLink audit payload as structured data. Tested integrations: Splunk (HEC + syslog), IBM QRadar (syslog CEF), Microsoft Sentinel (HTTP Data Connector).

Key Configuration

• Output mode (UDP / TCP-TLS / webhook)
• Endpoint hostname and port
• Format (syslog / CEF / JSON)
• Authentication token (for webhook / HEC)
• Event filter by action type
• Batch size and flush interval

Secret scanning uses a combination of regex patterns and Shannon entropy analysis to detect exposed credentials in source code, configuration files, and documentation. The pattern library covers 40+ service-specific formats including AWS access keys, GitHub tokens, Stripe API keys, and database connection strings. Custom patterns can be added per workspace.

Scanning runs via the Transit Agent (for repository scanning) or the Scan Agent (for CI/CD pipeline integration). Findings are deduplicated by fingerprint and linked to CoreLink vault entries when a match exists.

Key Configuration

• Pattern library selection (built-in + custom)
• Entropy threshold for generic detection
• Scan scope (repositories, directories, CI pipelines)
• Finding severity classification rules

Secret sprawl detection maps where each secret is consumed across your infrastructure -- which applications, services, and pipelines reference it. The analysis identifies duplicated credentials (the same value stored under different names), unused secrets (no read access in N days), and over-shared access (secrets readable by more users than necessary).

Each secret receives a sprawl risk score based on duplication count, access breadth, and staleness. The dashboard prioritizes secrets by sprawl score to guide consolidation and cleanup efforts.

Key Configuration

• Staleness threshold (days since last read)
• Duplication detection sensitivity
• Over-sharing threshold (max readers per secret)
• Sprawl score weights

User and Entity Behavior Analytics establishes a rolling 30-day baseline of normal access patterns per user and service account. Anomaly scoring flags: access volume significantly above peer group average, secrets accessed outside historical working hours, first-time access to a resource or workspace, bulk secret enumeration in a short window, and repeated failed access attempts.

Flagged events appear in the Security Events queue with an anomaly score and contributing factors. High-score events can trigger automatic approval requirement escalation.

Key Configuration

• Baseline window (days)
• Peer grouping (workspace / role / department)
• Anomaly score threshold for alerting
• Automatic escalation threshold
• Suppression rules for known automation accounts

The Application-to-Application agent protocol enables workloads to authenticate to CoreLink and retrieve secrets without human intervention. Each A2A agent is issued a rotating token bound to a specific workspace and permission set. Authentication uses mutual TLS with automatic certificate renewal.

A2A agents are tracked in the NHI registry with the same ownership, expiry, and risk scoring as other non-human identities. Token rotation happens automatically with zero downtime using a dual-token overlap window.

Key Configuration

• Agent token rotation interval
• Workspace and permission scope
• mTLS certificate authority
• Dual-token overlap window

Adaptive Overload Protection computes a rolling health score from request latency, queue depth, database saturation, and error rate. As the score degrades, CoreLink progressively sheds load: first deferring non-critical background jobs, then throttling bulk operations, and finally rejecting low-priority requests with a 503 and Retry-After header while preserving critical flows (authentication, audit log writes, break-glass unseal).

The overload dashboard visualizes the current health score, active shedding rules, and recent rejection counts by priority tier. Thresholds are tunable per tenant for SaaS deployments or per region for self-hosted clusters.

Key Configuration

• Health score component weights
• Shedding thresholds per priority tier
• Always-allowed critical paths
• Metric export interval

Migrate secrets from existing vaults and configuration stores without manual re-entry. Supported input formats: JSON array, CSV (key/value/metadata columns), and HashiCorp Vault KV v2 export. Import maps secrets to a target workspace and environment, applies default rotation schedules, and encrypts each secret with the workspace KEK before persisting.

Dry-run mode previews the import without writing, reporting conflicts with existing secret names. A progress log is available in real time during import.

Key Configuration

• Input format (JSON / CSV / Vault KV v2)
• Target workspace and environment
• Conflict resolution (skip / overwrite / version)
• Default rotation schedule
• Dry-run flag

CoreLink integrates with CI/CD platforms to inject secrets at build time and scan for exposed credentials in pipeline artifacts. The GitHub Actions step (techblend/corelink-scan-action@v2) runs as a pre-merge check, blocking pull requests that introduce leaked secrets. Similar plugins are available for GitLab CI and Jenkins.

For secret injection, pipelines authenticate with a workspace-scoped API key and retrieve secrets via the SDK or CLI. Secrets are injected as environment variables and never written to disk.

Key Configuration

• CI platform (GitHub Actions, GitLab CI, Jenkins)
• API key scope (workspace, environment)
• Scan action failure mode (block / warn)
• Secret injection method (env var, file mount)

Data Export produces a complete archive of a user's personal data -- profile attributes, access history, approval decisions, audit events they appear in -- for GDPR Article 15 and CCPA subject access requests. Exports are generated asynchronously, encrypted at rest, and delivered via a time-limited signed download URL.

Format options include JSON (machine-readable) and CSV (spreadsheet-friendly). Download tokens expire after a configurable window, and every export request is logged with requester, subject, and delivery confirmation for evidence purposes.

Key Configuration

• Export format (JSON, CSV)
• Download token TTL
• Scope (user-only, user + related workspace data)
• Retention of generated archives

The developer console provides a dedicated workspace for managing API keys, app registrations, webhook endpoints, and integration testing. Developers can view API request logs filtered by endpoint and status code, test webhook delivery with sample payloads, and manage OAuth2 client credentials for external integrations.

App registrations support scoped API keys with per-resource permissions, rate limits, and expiration policies. Each registration is tracked in the audit log with full lifecycle events.

Key Configuration

• App registration permissions
• API key expiration policy
• Rate limit per app registration
• Webhook test endpoint

The event bus provides a pub/sub interface for reacting to CoreLink lifecycle events in real time. Subscribers receive structured JSON payloads for secret creation, rotation, access, session start/end, approval decisions, and compliance violations. Events can be filtered by type, workspace, and severity.

The event bus powers the webhook delivery system and can also be consumed directly by internal services for custom automation workflows. Delivery uses at-least-once semantics with configurable retry policies.

Key Configuration

• Subscriber endpoints (webhook URL, internal service)
• Event type filter
• Retry policy (max attempts, backoff)
• Dead letter queue

Knox is CoreLink's built-in conversational AI assistant. A floating chat widget is available on every page, answering questions about the platform, navigating users to the right screen, and executing common actions through tool calls (list secrets in a workspace, open an approval queue, look up an audit event). Knox respects the signed-in user's permissions -- it cannot access data or perform actions the user is not authorized for.

Offline detection disables the assistant gracefully when the LLM backend is unreachable. Conversations are scoped to the user and can be trashed or restored. Administrators can configure the underlying model and provider per tenant.

Key Configuration

• LLM provider and model
• Allowed tool set
• Conversation retention
• Offline fallback behavior

CoreLink exposes an MCP (Model Context Protocol) server that AI coding assistants and agents can use to read secret metadata, list workspaces, and retrieve non-sensitive configuration without embedding credentials in prompts. Tools include: get_secret_metadata (name, type, last-rotated, workspace), list_secrets (filterable by workspace/environment), list_workspaces, and get_rotation_status.

Secret values are never returned through MCP tools; the assistant receives only metadata sufficient to construct correct application configuration.

Key Configuration

• MCP server enable / disable
• Allowed tool set per workspace
• Token scopes for MCP-issued JWTs
• Rate limit per tool per minute

CoreLink delivers user-facing notifications over email and SMS. Email providers supported: SMTP, SendGrid, Mailgun, AWS SES, Postmark, and Resend. SMS providers: Twilio, Vonage, Sinch, and AWS SNS. Each provider is configured per tenant with credential storage in the vault (never in plaintext config).

Notification templates cover approval requests, access reviews, MFA OTP delivery, rotation failures, and compliance violations. Test-send functionality lets administrators verify delivery before enabling each channel in production.

Key Configuration

• Email provider (SMTP, SendGrid, Mailgun, SES, Postmark, Resend)
• SMS provider (Twilio, Vonage, Sinch, SNS)
• Default sender identity
• Per-template enable/disable

Session recordings can be archived to external object storage (S3, GCS, Azure Blob) with configurable retention per tenant. Recordings are encrypted at rest with a workspace-scoped data key wrapped by the tenant KEK, and storage credentials are themselves stored in the CoreLink vault for rotation.

Rekey operations re-wrap existing recordings under a new KEK without re-encrypting the underlying recording payload -- fast and cheap even across millions of recordings. Retention policies enforce automatic deletion after the configured window.

Key Configuration

• Storage backend (S3, GCS, Azure Blob)
• Retention period (days)
• KEK rotation schedule
• Storage credential source (vault secret reference)

CoreLink includes a built-in ticketing system for internal support operations. Tickets support priority levels, custom fields, threaded comments, file attachments, and SLA tracking with breach alerts. Canned responses let agents answer common questions quickly, and CSAT surveys capture feedback on resolution quality.

Tickets integrate with the approvals engine so an access request can attach an associated support ticket, and every state transition is captured in the audit log alongside other tenant events.

Key Configuration

• Priority-specific SLA targets
• Custom field definitions
• Canned response library
• CSAT survey timing (on resolve, 24h after close)

The Transit Agent is a lightweight process that runs inside a customer network segment and brokers connections between CoreLink and internal resources that are not directly reachable from the platform. It handles: dynamic credential injection for applications that cannot use the API, Git repository scanning for secret detection, and outbound-only connectivity so no inbound firewall rules are required.

Agents authenticate to CoreLink with a rotating agent token and communicate over mTLS.

Key Configuration

• Agent token (auto-rotated)
• Allowed resource CIDRs
• Tunnel keep-alive interval
• Proxy settings for outbound HTTPS
• Log level

Usage Metering tracks consumption metrics per tenant: active users and NHIs, secrets count, rotations executed, sessions recorded, transit operations, and audit events ingested. Metrics update in near real time and are exposed through the Billing API for integration with external billing systems.

Tier definitions cap specific metrics; requests that would exceed the tier's limit are rejected with a structured quota error, and administrators receive warnings before the cap is reached.

Key Configuration

• Metric collection interval
• Per-tier quota definitions
• Quota warning threshold (percent of limit)
• Billing API webhook endpoint

CoreLink emits webhook events for key lifecycle transitions: secret created/updated/rotated/deleted, session started/ended, approval granted/denied, and compliance violation detected. Each webhook endpoint is configured with a URL, HMAC-SHA256 signing secret, and event filter.

Delivery uses at-least-once semantics with exponential backoff (5 retries over 30 minutes). Failed deliveries are logged and retryable from the admin UI. Payloads are JSON and include a X-CoreLink-Signature-256 header for verification.

Key Configuration

• Endpoint URL
• Signing secret
• Event filter (comma-separated event types)
• Timeout (seconds)
• TLS verification

Four agent binaries extend CoreLink beyond the SaaS boundary. All support macOS, Linux, and Windows across amd64 and arm64. Download links on the Registry. All agents authenticate via NHI passwordless attestation -- no tokens, no certificates, no API keys.

# No configuration file needed.
# Set two environment variables and start the agent:
NHI_ID=<your-nhi-id>          # from Self-Service → NHI Onboarding
PLATFORM_URL=https://usecorelink.com

sudo systemctl enable --now corelink-agent

VER=1.0.1
BASE=https://usecorelink.com/static/downloads/v$VER

curl -LO $BASE/corelink-transit-agent-v$VER-linux-amd64.tar.gz
tar -xzf corelink-transit-agent-v$VER-linux-amd64.tar.gz
sudo mv corelink-transit-agent /usr/local/bin/

containers:
  - name: agent
    image: ghcr.io/dw-develop/corelink-transit-agent:latest
    env:
      - name: NHI_ID
        valueFrom:
          secretKeyRef:
            name: nhi-ids
            key: transit-nhi-id
      - name: PLATFORM_URL
        value: "https://usecorelink.com"

npx @corelink/mcp-server

{
  "mcpServers": {
    "corelink": {
      "command": "npx",
      "args": ["-y", "@corelink/mcp-server"],
      "env": { "CORELINK_API_KEY": "sk_live_..." }
    }
  }
}

# macOS / Linux
corelink-scan --dir /path/to/repo --output json

# Windows (PowerShell)
.\corelink-scan.exe --dir C:\repos\myapp --output json

- uses: techblend/corelink-scan-action@v2
  with:
    api-key: ${{ secrets.CORELINK_API_KEY }}
    fail-on-findings: true

# Install and register the Windows Service (TBCLWindowsAgent)
.\tbcl-windows-agent.exe install `
  --platform https://usecorelink.com `
  --nhi-id <your-nhi-id> `
  --target-id <target-id>

# Start the service
sc start TBCLWindowsAgent

# Verify it is running
Get-Service -Name TBCLWindowsAgent

.\tbcl-windows-agent.exe run `
  --platform https://usecorelink.com `
  --nhi-id <your-nhi-id> `
  --target-id <target-id> `
  --fps 5

.\tbcl-windows-agent.exe uninstall

The corelink CLI manages secrets, triggers rotation, runs scans, and administers tenants from any terminal. Binaries for macOS, Linux, and Windows are published on the Registry page, each covered by a SHA256 manifest you can verify before running it.

curl -fsSL https://usecorelink.com/install.sh | sh

VER=1.0.1
BASE=https://usecorelink.com/static/downloads/v$VER

# pick your platform: darwin-arm64, darwin-amd64, linux-amd64, linux-arm64
curl -LO $BASE/corelink-cli-v$VER-darwin-arm64.tar.gz
curl -LO $BASE/corelink-v$VER-checksums.txt
shasum -a 256 -c corelink-v$VER-checksums.txt --ignore-missing

tar -xzf corelink-cli-v$VER-darwin-arm64.tar.gz
sudo mv tbcl-cli /usr/local/bin/corelink

# Windows: download corelink-cli-v$VER-windows-amd64.zip and add it to your PATH

Command Reference

Transit client libraries for Go, Python, Java, and .NET are bundled with the platform under sdk/. Each library handles NHI attestation, automatic secret refresh, retry with exponential backoff, and in-memory delivery with envelope encryption. See the Registry for versioned archives.

go get github.com/techblend/secrets-mgmt/sdk/go/transit

import (
    "os"
    "github.com/techblend/secrets-mgmt/sdk/go/transit"
)

func main() {
    client := transit.NewClient("http://transit-agent:9090", transit.Options{
        NHIID:       os.Getenv("NHI_ID"),
        PlatformURL: os.Getenv("PLATFORM_URL"),
    })
    client.Bootstrap()
    secret, err := client.GetSecret("my-db-password")
    if err != nil { log.Fatal(err) }
    fmt.Println(secret)
}

pip install ./sdk/python

import os
from transit_client import TransitClient

client = TransitClient(
    transit_url="http://transit-agent:9090",
    nhi_id=os.environ["NHI_ID"],
    platform_url=os.environ["PLATFORM_URL"],
)
client.bootstrap()
secret = client.get_secret("my-db-password")
print(secret)

<dependency>
  <groupId>io.techblend</groupId>
  <artifactId>transit-client</artifactId>
  <version>1.0.1</version>
</dependency>

TransitClient client = new TransitClient(
    "http://transit-agent:9090",
    System.getenv("NHI_ID"),
    System.getenv("PLATFORM_URL")
);
client.bootstrap();
String secret = client.getSecret("my-db-password");
System.out.println(secret);

dotnet add package TechBlend.TransitClient --source ./sdk/dotnet

using TechBlend.Transit;

var client = new TransitClient(
    "http://transit-agent:9090",
    Environment.GetEnvironmentVariable("NHI_ID"),
    Environment.GetEnvironmentVariable("PLATFORM_URL")
);
await client.BootstrapAsync();
var secret = await client.GetSecretAsync("my-db-password");
Console.WriteLine(secret);

tar -xzf corelink-sdk-node.tar.gz
npm install ./node

const { TransitClient } = require("@techblend/transit");

const client = new TransitClient({
    transitUrl: "http://transit-agent:9090",
    platformUrl: process.env.PLATFORM_URL,
    nhiId: process.env.NHI_ID,
});

await client.bootstrap();
const secret = await client.getSecret("my-db-password");

tar -xzf corelink-sdk-ruby.tar.gz
gem build ruby/transit_client.gemspec && gem install techblend-transit-*.gem

require "transit_client"

client = TransitClient::Client.new(
  transit_url: "http://transit-agent:9090",
  platform_url: ENV["PLATFORM_URL"],
  nhi_id: ENV["NHI_ID"]
)

client.bootstrap
secret = client.get_secret("my-db-password")