Security Intelligence at the Moment of Decision
KRYOS-XS Cyber Decision Assurance Platform
KRYOS-XS transforms fragmented cybersecurity signals into safe, explainable, authorized and verifiable decisions, without requiring organizations to replace the security tools they already use.
KRYOS-XS protects decisions, not just systems. It detects consequential actions, determines what the evidence justifies, identifies who has authority, recommends the safest response and preserves proof of what the organization decided and why.
Instead of creating another stream of alerts, KRYOS-XS helps organizations understand what is happening, determine what the evidence justifies, identify who has authority, guide the safest response and preserve a complete decision record.
The problem
Security tools produce signals. Organizations still have to decide.
Most cybersecurity investment improves detection. The gap that remains is the decision, and that is where public-interest organizations are least resourced.
01
Security tools produce more signals than any organization can review, and most of those signals never resolve into a decision.
02
The people asked to act are often not the people holding the evidence, and the evidence is spread across systems that do not talk to each other.
03
Judgments are made under time pressure, then repeated by different people who cannot see what was decided before or why.
04
When a funder, auditor or board asks what happened, the record has to be reconstructed from memory and disconnected logs.
Platform structure
Two products, one reasoning layer, one permanent record
KRYOS-XS Edge and KRYOS-XS Console are the two places a decision is made. The Hypercube Decision Engine reasons for both, and the KRYOS Decision Ledger preserves what was decided and why.
Inline decision assistant
KRYOS-XS Edge
A browser-based security decision assistant that helps users evaluate suspicious messages, external data sharing, OAuth approvals and other consequential actions at the moment they occur.
Cyber Decision Operations Hub
KRYOS-XS Console
A centralized Cyber Decision Operations Hub that converts alerts, identity risks, access questions, data exposures and response requirements into one prioritized decision queue.
Shared reasoning layer
Hypercube Decision Engine
The shared reasoning layer that cross-checks evidence, evaluates competing explanations, identifies uncertainty, applies organizational policy and recommends the safest justified action.
Permanent decision record
KRYOS Decision Ledger
The permanent organizational record of evidence, confidence, authority, recommendations, human decisions, actions and verified outcomes.
Edge and Console
Two products that answer different questions
Edge decides in the moment, on the surface where the action is happening. Console decides across the organization, where responsibility and reporting live.
| Aspect | KRYOS-XS Edge | KRYOS-XS Console |
|---|---|---|
| Where it works | In the browser, on approved work surfaces | In a central hub for the whole organization |
| When it acts | While the action is still being taken | After a signal or request arrives for review |
| Who uses it | Any staff member performing a consequential action | Whoever holds operational or governance responsibility |
| What it returns | One of five inline verdicts with reasoning | A prioritized decision with evidence, authority and deadline |
| Primary value | Prevents a risky action before it completes | Organizes and governs everything that still needs deciding |
Core workflow
Nine steps from a detected action to a preserved record
Every consequential decision follows the same sequence, whether it is raised inline by Edge or queued in the Console.
Step 01
Detect the action
Step 02
Gather evidence
Step 03
Cross-check the facts
Step 04
Evaluate risk
Step 05
Apply policy
Step 06
Confirm authority
Step 07
Recommend action
Step 08
Verify the outcome
Step 09
Preserve the record
Overlay architecture
ArtOfTheHack operates above the stack, never inside it
ArtOfTheHack does not replace SIEM, XDR, EDR, NDR, SOAR, IAM, PAM, ZTNA, CNAPP, DLP, or cloud control planes. It operates above them as a non-intrusive API overlay and returns governed decisions to those systems.
- Evidence in (read-scoped)
- Governed instruction out
- Executed by existing controls
Integration methods
- REST APIs and webhooks
- Event streams and message queues
- Batch ingestion and secure file transfer
- Database and warehouse connectors
- Grantee organization-controlled gateways
- Organization SDKs and private connectors
Failure behavior
If ArtOfTheHack is unavailable, existing systems continue operating under their own controls. Native fallback is an architectural requirement, and automation can be halted immediately at workflow, environment, or tenant scope.
Hypercube Decision Engine
The shared reasoning layer behind both products
A consequential decision is rarely a single-variable question. The Hypercube evaluates the dimensions that determine whether an action is defensible, together rather than in sequence.
01
Identity and entitlement
02
System and asset state
03
Exposure and reachability
04
Business and operational impact
05
Policy and regulatory constraint
06
Time, sequence, and freshness
07
Authority and approval thresholds
08
Reversibility and rollback
09
Confidence and uncertainty
10
Contradiction and source independence
Decision lifecycle
Ten stages, one retained record
Each stage narrows the space of defensible action. Nothing is discarded silently, and calibration returns observed outcomes to the reasoning core.
- Reasoning stages 01-06
- Authority and execution 07-10
- Calibration feedback
KRYOS Decision Ledger
The permanent record of what was decided and why
Every decision produces a structured object. It is exportable, replayable, and complete enough for an independent reviewer to re-derive the determination.
- What was determined, on what evidence
- Consequence and who may approve
- Limits and reversal
- Audit and replay
| Field | Detail |
|---|---|
| Decision | The adjudicated determination produced by the reasoning engine for a single consequential question. |
| Requested action | The specific instruction proposed for execution in an existing enforcement or workflow system. |
| Primary hypothesis | The best-supported explanation of the observed evidence at the time of adjudication. |
| Alternative hypotheses | Competing explanations retained and scored so dissenting interpretations remain visible. |
| Supporting evidence | Normalized, timestamped, source-attributed records that support the primary hypothesis. |
| Contradictory evidence | Records that conflict with the primary hypothesis and were weighed rather than discarded. |
| Evidence quality | Source reliability, freshness, independence, and completeness scoring for each contributing record. |
| Risk score | Contextual risk of the requested action and of inaction, expressed against organization-defined scales. |
| Confidence | How strongly the retained evidence supports the primary hypothesis. |
| Uncertainty | What remains unknown, including missing evidence that would change the determination. |
| Mission impact | Modeled operational, programmatic, safety, and continuity consequence of the requested action. |
| Recommended controls | Constraints that reduce blast radius while preserving the intent of the action. |
| Required authority | The role or roles permitted to approve this class of action under current policy. |
| Approval status | Pending, approved, denied, or expired, with the identity of the approving authority. |
| Validity window | The period during which the decision remains valid before re-evaluation is required. |
| Expiration conditions | Evidence or state changes that invalidate the decision before its validity window closes. |
| Rollback plan | The predefined reversal path, including the systems and sequence required to restore prior state. |
| Audit hash | A tamper-evident cryptographic digest of the decision inputs, policy state, and outputs for independent verification. |
| Model version | The exact reasoning and scoring versions used, so the decision can be replayed faithfully. |
| Policy version | The exact policy and authority configuration in force at the moment of adjudication. |
| Human overrides | Any authorized deviation from the recommended action, with rationale and identity. |
| Final outcome | The observed result after execution, used for calibration of future decisions. |
Agentic control
Agent intent is evaluated before it becomes action
Access control authenticates an actor. It does not decide whether a specific action, at this consequence level, in this context, should proceed.
- Requested intent
- Bounded execution
- Approval required first
- Denied, no action
Operating modes
Advisory, approval-gated, and bounded automatic
Deployments normally begin in advisory mode with read-only scopes, and autonomy is extended only where reversal is validated.
ArtOfTheHack evaluates the evidence and recommends an action to an authorized person inside the grantee organization.
Human authority required: named approver
Governance rail
Controls present in every deployment
Control 01
Human in the loop
Named people inside the grantee organization remain accountable for consequential outcomes.
Control 02
Approval thresholds
Consequence and risk determine which actions require which approver.
Control 03
Separation of duties
Requesting, approving, and executing roles can be held apart.
Control 04
Policy constraints
Actions outside policy are never prepared for execution.
Control 05
Reversibility checks
Automatic execution requires a validated rollback path.
Control 01
Blast-radius limits
Grantee-defined maximums bound the scope of any single action.
Control 02
Audit logging
Every input, version, and approval is retained for replay.
Control 03
Compliance mapping
Decision records can be mapped to the grantee's control frameworks and funder reporting.
Control 04
Kill switch
Automation can be halted immediately at tenant or workflow scope.
Control 05
Native fallback
If ArtOfTheHack is unavailable, existing systems continue to operate unchanged.
Initial deployment
Deployment begins with Google Workspace
The first connection is the one that carries the most evidence for most public-interest organizations.
- Google Workspace is the initial deployment surface, because it is where most public-interest organizations hold their mail, files and identities.
- The connection is read-only by default and uses the minimum scopes each capability requires.
- Alert, identity, sharing and configuration evidence is read from the Workspace APIs rather than reconstructed from user reports.
- Google remains the system of record and the point of enforcement. Any action is executed by Google's own API after a named human approves it.
Capability status
Current, pilot, planned and long term
Additional integrations beyond Google Workspace require a real, approved technical connection. Until that connection is authorized and validated, the capability is planned, not available.
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.
Trust architecture
What the overlay does, and what it will never do
Twelve commitments that apply to every grant-funded deployment, stated so a nontechnical executive, a systems administrator, and an employee whose browser it runs in can all check them.
Default product behavior
Approved work surfaces
Edge is active only on the work applications the organization authorizes, such as its mail, drive, and administration consoles. Any other site is out of scope.
Default product behavior
No unrelated browser monitoring
Personal browsing, unrelated tabs, and non-work accounts are not read, recorded, or sent anywhere. There is no general web-history collection.
Default product behavior
Least-privilege permissions
Each connection requests the narrowest scope the workflow needs, and the organization can review or revoke any scope at any time from its own admin console.
Default product behavior
Read-only advisory operation by default
Every deployment starts without write capability. KRYOS-XS explains and recommends; it changes nothing until the organization decides to enable a bounded action.
Default product behavior
Human authorization for high-impact actions
Consequential actions such as disabling an account or revoking access require a named human with the authority to approve them. That authority is never assumed by the system.
Default product behavior
Evidence provenance
Every determination carries the evidence behind it, where each item came from, and when it was observed, so a reviewer can retrace the reasoning later.
Default product behavior
Uncertainty and escalation
Confidence and missing evidence are reported with the decision. When evidence is insufficient or contradictory, the workflow escalates to a person instead of guessing.
Default product behavior
Reversible actions
Any action eligible for bounded execution must have a validated way to undo it, recorded alongside the decision that authorized it.
Default product behavior
Decision logging
The KRYOS Decision Ledger records what was decided, on what evidence, under which policy version, and who approved it. Records are exportable in structured form.
Default product behavior
Organization-controlled policies
Thresholds, approval roles, escalation rules, and the limits of any automated action are defined by the organization, not preset by ArtOfTheHack.
Set in the award agreement
Data isolation
Each organization's evidence, policy, and decision records are kept separate from every other organization's. Stronger separation, including dedicated or organization-hosted deployment, is available where the award scope supports it.
Set in the award agreement
Configurable retention
Retention periods for evidence and decision records are chosen by the organization, along with the deletion process that applies when a period ends.
These are the operating commitments of the platform and the award agreement, described as designed and delivered. They are not a certification, an independent security audit, or a compliance attestation, and ArtOfTheHack does not claim any. Protections that depend on the deployment model are scoped in writing with each grantee before connection.
Expandable integration model
Coverage extends only as far as the organization authorizes
Each stage is a separate authorization. Nothing is connected by default and any connection can be withdrawn.
Stage 01
Google Workspace
- Initial deployment surface
- Alert, identity and sharing evidence
- Read-only default
Stage 02
Edge on approved surfaces
- Mail, sharing and cloud consoles
- Five-verdict decisioning
- Dormant everywhere else
Stage 03
Console decision operations
- One prioritized queue
- Guided response workflows
- Decision Ledger reporting
Stage 04
Identity expansion
- Identity-provider integration
- Okta and Entra ID
- Microsoft 365 security
Stage 05
Detection and cloud estate
- SIEM alert investigation
- EDR and MDM triage
- Vulnerability and backup evidence
Who the platform serves
Public-interest organizations carrying institutional risk
KRYOS-XS is provided to mission-driven organizations that hold sensitive information and rarely hold a dedicated security team.
Nonprofits
NGOs
Think tanks
Foundations
Research institutes
Humanitarian organizations
Public-interest organizations
International coalitions
Deployment
Deployment is a control decision
The model an institution chooses determines where evidence is processed, who holds the keys, and how the environment is isolated.
Grant-hosted multi-tenant overlay
Logically isolated tenancy operated by ArtOfTheHack under the grant. The default for small and mid-size nonprofits with no infrastructure team.
Dedicated private tenancy
Single-tenant infrastructure with dedicated compute, storage, and key material for organizations handling at-risk populations.
Grantee-controlled virtual private cloud
Deployment inside the organization's own cloud account with organization-held network and key control.
On-premises or isolated deployment
Installation inside grantee facilities or disconnected environments for restricted research or field workloads.
Availability of each deployment model depends on grant tier, award scope, and implementation requirements.
Grant funding is provided by James Scott and administered through the Embassy Row Project. ArtOfTheHack manages cybersecurity assessment, deployment and technical support.