Integration

A Non-Intrusive API Overlay

The overlay reads from the systems already in operation, reasons over what they collectively mean, and returns a bounded instruction through the same APIs your teams already administer. Systems of record and enforcement remain authoritative.

Apply for Grant-Funded Access Review the Architecture

Placement

Between Security Evidence and Security Action

Primary control surface: Identity-centric Zero Trust policy decisioning: IAM, PAM, CIEM, ZTNA, API authorization, and policy-based access mediation.
Primary intelligence surface: XDR, SIEM, SOAR, EDR, NDR, CNAPP, threat intelligence, vulnerability management, and data security.
Primary function: Correlate evidence, resolve contradictions, calculate contextual risk, simulate response options, govern authority, and deliver an auditable decision to the existing enforcement system.

Telemetry in
Governed decision
Approved response
Outcome and calibration back to evidence

Boundaries

What the Overlay Does Not Replace

The category is decision infrastructure. It is not a substitute for collection, enforcement, or storage.

Endpoint agents

Firewalls and packet inspection

Identity providers

Deterministic policy engines

Malware scanners

SIEM storage

SOAR execution engines

Cryptographic infrastructure

Inbound

How Evidence Arrives

Authenticated connectors operate at defined workflow boundaries, scoped to the minimum data required for the decision in question.

REST APIs

Identity, asset, vulnerability, cloud, and policy data pulled on a scoped schedule.

Signed webhooks

Detections and access requests delivered at the moment they occur.

Event streams

High-volume security telemetry consumed continuously.

Batch submission

Historical incidents and control assessments for replay and calibration.

TAXII collections

Threat intelligence exchanged over the standard RESTful protocol.

Read-only connectors

Database or data-lake reads where a product exposes no usable API.

Normalization

Vendor-Neutral Schemas

Evidence is translated into open, machine-readable representations before any reasoning occurs, so conclusions do not depend on a single vendor's interpretation.

OCSF

Security events and detections

A JSON-based, implementation-agnostic schema for representing cybersecurity events across products and platforms.

STIX 2.1

Indicators, actors, campaigns, attack patterns, relationships

A machine-readable language for cyber-threat intelligence; TAXII carries it between parties.

MITRE ATT&CK

Adversary technique mapping

Used as a standardized behavioral vocabulary, not as a detection engine in itself.

MITRE D3FEND

Defensive countermeasure mapping

A knowledge graph used to move from a suspected technique to a contextually appropriate defensive action.

OpenTelemetry / OTLP

Application traces, logs, metrics, execution context

Transport for telemetry between sources, collectors, and backends where application context is relevant.

Evidence envelope

Internal provenance wrapper

Source, hash, timestamp, tenant, authority, quality, freshness, and lineage attached to every item.

Evidence layer functions

Schema normalization across vendor formats
Provenance capture and cryptographic hashing
Validation against expected structure and range
Deduplication of repeated and mirrored events
Entity resolution across identity, asset, and workload namespaces
Temporal alignment of observations recorded on different clocks
Evidence quality scoring for reliability, freshness, and independence

Contracts

Cyber Decision Endpoints

Retrieval scoring, claims classification, contradiction scanning, provenance, and release gating operate behind these domain-specific contracts.

Method	Endpoint	Purpose
POST	/v1/cyber/events/ingest	Submit normalized security events and detections.
POST	/v1/cyber/incidents/evaluate	Adjudicate an incident hypothesis from correlated evidence.
POST	/v1/cyber/access/evaluate	Evaluate an access or privilege request in context.
POST	/v1/cyber/exposure/prioritize	Rank exposures by exploitability, reachability, and consequence.
POST	/v1/cyber/actions/simulate	Model the operational effect of a proposed control action.
POST	/v1/cyber/actions/authorize	Apply policy, authority, and release gates to an action.
POST	/v1/cyber/threat-intelligence/score	Score reliability, freshness, relevance, and corroboration.
POST	/v1/cyber/contradictions/scan	Detect material disagreement across evidence sources.
POST	/v1/cyber/outcomes	Return the observed result of an executed decision for calibration.
GET	/v1/cyber/decisions/{decision_id}	Retrieve a governed decision object.
GET	/v1/cyber/decisions/{decision_id}/audit	Retrieve the full audit and provenance record.

Example request body

{
  "request_id": "req_01",
  "tenant_id": "enterprise_01",
  "mode": "shadow",
  "subject": {
    "type": "human",
    "identity_id": "user_4821",
    "roles": ["cloud_operator"],
    "assurance_level": 3
  },
  "action": {
    "name": "assume_privileged_role",
    "requested_duration_minutes": 30
  },
  "resource": {
    "resource_id": "production_payments_cluster",
    "criticality": "critical",
    "data_classification": "restricted"
  },
  "context": {
    "device_id": "device_991",
    "device_managed": true,
    "network_zone": "remote",
    "authentication_method": "phishing_resistant_mfa",
    "behavioral_deviation": "elevated"
  },
  "evidence_refs": [
    "idp:event:123",
    "edr:event:456",
    "cnapp:finding:789",
    "siem:incident:321"
  ],
  "policy_envelope": {
    "workflow": "privileged_access",
    "jurisdiction": ["US"],
    "maximum_autonomy": "recommend_only",
    "human_approval_required": true
  }
}

Failure behavior

Never a Single Point of Failure

Availability of the decision layer must never be a precondition for the grantee organization operating their own security controls.

Every integration carries a pre-established fallback policy
If the decision layer is unavailable, control returns to the native deterministic system
A kill switch disables write paths without disabling read paths
Automated actions expire rather than persist indefinitely
No integration is permitted to make the decision layer a single point of failure

Integration documentation describes structure, contracts, and governance. Proprietary scoring thresholds, model configuration, and reasoning internals are not published.

Connection status

Deployment begins with Google Workspace

Google Workspace is the first evidence connection in every grant deployment. Every other integration described on this site is planned: it becomes real only when the organization authorizes the vendor API and ArtOfTheHack validates the connection.

Current

Built and operable inside a grant deployment today, on the surfaces the organization has authorized.

Google Workspace evidence connection
KRYOS-XS Edge on approved mail, sharing and cloud-console surfaces
KRYOS-XS Console decision queue and KRYOS Decision Ledger records

Pilot

Operated inside a bounded, time-limited grant pilot with pre-registered success criteria. Results are measured with the organization and are not published as product claims.

Guided response workflows under named human approval
Approval-gated actions on low-complexity action classes
Board and funder decision reporting from the Ledger

Planned

Designed and specified, but not connected until the relevant vendor API is authorized by the organization and validated by ArtOfTheHack. No such connection is claimed as live.

Identity-provider evidence, including Okta and Entra ID
SIEM, EDR and MDM alert evidence
Vulnerability, backup and cloud estate evidence

Long term

Platform direction. Not scheduled, not implied to exist, and never presented as available capability.

Broader cross-vendor decision fabric coverage
Sector policy packs co-developed with mission networks
Coalition-wide decision reporting across member organizations

Nothing on this site describes a customer, a completed pilot outcome, an accuracy rate, a certification, an award or an existing partnership. Integrations exist only where an organization has authorized a real technical connection.