KRYOS-XS Hypercube
Your Security Tools See Pieces of the Attack. KRYOS-XS Reasons Across the Whole Environment.
ArtOfTheHack applies KRYOS-XS Hypercube as a non-intrusive cybersecurity API overlay above the security systems an organization already operates. It brings together evidence from those systems, identifies material conflicts, evaluates possible explanations, models response consequences, applies institutional policy and authority, and returns a governed decision to the controls already responsible for enforcement.
Cybersecurity Decision Intelligence Powered by KRYOS-XS Hypercube
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.
Existing systems remain in place. Connections are scoped. Human authority remains explicit. Native controls execute approved actions.
What is KRYOS-XS Hypercube?
KRYOS-XS Hypercube is the cybersecurity reasoning and governance technology underlying ArtOfTheHack. It connects to approved cybersecurity systems through narrowly scoped, revocable interfaces, evaluates their combined evidence, challenges conflicting interpretations, models response consequences, applies policy and authority constraints, and produces a governed cybersecurity decision without replacing the security controls already in operation.
- Role
- A cybersecurity reasoning and governance overlay that sits above the security systems an organization already operates.
- Integration
- Scoped, revocable API interfaces. No agent, no inline appliance, no product replacement.
- Output
- A governed cybersecurity decision carrying interpretation, evidence, recommended control, authority, validity, rollback, and provenance.
- Authority boundary
- Institutional policy and named human approvers determine what may execute. Native controls perform enforcement.
The decision workflow
Ten Steps From Connection to Institutional Memory
Every KRYOS-XS decision follows the same ordered sequence, whether it is resolved inline by KRYOS-XS Edge or reviewed in KRYOS-XS Console.
Step 01
Connect approved systems
The organization authorizes each connection, with the minimum scope the capability needs.
Step 02
Detect a consequential event or action
A signal, request or in-progress action is identified as one that deserves a decision.
Step 03
Gather authoritative evidence
Facts are read from the connected systems, with the source and age of each recorded.
Step 04
Cross-check safe and dangerous explanations
Competing explanations are tested against the evidence rather than assuming the worst or the best.
Step 05
Estimate risk, consequence and confidence
The likely harm, the reversibility and the confidence in the evidence are stated explicitly.
Step 06
Apply organizational policy
The organization's own written rules are applied, not a generic template.
Step 07
Identify the required authority
The person or role who must approve the action is named before the action is offered.
Step 08
Recommend or escalate the safest action
The least disruptive defensible response is proposed, with alternatives and rollback conditions.
Step 09
Verify the result
The action is confirmed to have taken effect in the connected system.
Step 10
Preserve the complete decision record
Evidence, reasoning, authority, action and outcome are written to the KRYOS Decision Ledger.
Traditional cybersecurity
- 1. Alerts
- 2. Dashboards
- 3. Manual interpretation
- 4. Fragmented response
KRYOS-XS
- 1. Evidence
- 2. Decision
- 3. Authority
- 4. Guided action
- 5. Verified outcome
- 6. Institutional memory
Platform division of labor
One Platform. Two Different Jobs. Zero Rip-and-Replace.
Non-disruptive to your existing technology. Disruptive to alert-heavy cybersecurity workflows.
KRYOS-XS is designed to strengthen the cybersecurity environment an organization already has, not replace it.
Existing tools such as SIEM platforms, identity providers, endpoint protection, cloud-security systems and collaboration applications continue performing their specialized jobs. KRYOS-XS connects their approved signals, organizes the evidence and transforms fragmented alerts into clear, prioritized and governed decisions.
The platform then divides responsibility between two complementary products. KRYOS-XS Edge protects individual users at the moment of action. KRYOS-XS Console gives administrators and security teams centralized visibility, governance, response coordination and institutional memory.
Edge and Console do not duplicate each other. They protect two different stages of the same decision lifecycle.
Keep the Tools. Transform the Decisions.
Traditional cybersecurity environments often contain capable tools that operate independently. Each tool detects a different type of activity and generates its own alerts, dashboards and reports. The result can be excessive noise, fragmented evidence and slow manual interpretation.
KRYOS-XS operates as a non-replacement cybersecurity intelligence layer. It receives approved signals from existing systems, normalizes different data formats and routes the evidence through the Hypercube Decision Engine.
Hypercube cross-checks the available evidence, compares safe and dangerous explanations, identifies missing information, evaluates potential consequences, applies organizational policy and recommends the safest justified action.
The result is not another disconnected alert. It is an evidence-backed decision with a clear owner, confidence level, recommended response and permanent audit record.
Plain-language summary
Existing tools detect. KRYOS-XS helps the organization decide.
Detection stays with the systems built for it. KRYOS-XS adds the reasoning, ownership and record that turn a detection into a defensible decision.
Systems view
How KRYOS-XS Works With the Security Stack You Already Have
Every zone below is readable as plain text whether or not the sequence is running. Use the controls to play, pause, replay, or move one stage at a time.
Architecture description, in five zones. Zone 1: your existing security tools (SIEM, identity provider, endpoint security, cloud security, email security, collaboration and file sharing, backup, and vulnerability management) stay in place and keep running. Zone 2: only the signals your organization approves are collected, deduplicated, normalized and linked into a consistent evidence structure. Zone 3: that evidence enters the KRYOS-XS Hypercube decision engine, which cross-verifies it, weighs competing explanations, risk, confidence, policy and authority, and produces a structured decision with a recommended action rather than a raw score. Zone 4: the decision splits between two complementary products that do different jobs. KRYOS-XS Edge returns an inline verdict to the person in the browser at the moment of action, and KRYOS-XS Console gives administrators a prioritized queue, review, approval and reporting across the organization. Edge sends its evidence and outcome to the Console. Zone 5: both products write to the same Decision Ledger, a permanent record of the event, evidence, confidence, recommendation, authority, action and outcome. Nothing in the existing stack is replaced.
Zone 1
Active nowYour Existing Security Stack
Existing tools continue detecting, protecting and recording activity.
Always active · never replaced
Zone 2
Approved Signals and Evidence
Fragmented alerts from many tools become one consistent evidence structure.
- 1Collection
- 2Deduplication
- 3Normalization
- 4Entity linking
- 5Evidence preparation
Zone 3
Hypercube Decision Engine
Evidence is evaluated across several dimensions at once, and a structured decision emerges.
- Cross-verification
- Competing explanations
- Risk and consequence
- Confidence and uncertainty
- Policy
- Authority
- Recommended action
Zone 4 · Edge
KRYOS-XS Edge
Real-time, decentralized protection at the moment of action.
Inline verdict
- Allow
- Warn
- Approval required
- Stop
- Insufficient evidence
Zone 4 · Console
KRYOS-XS Console
Centralized decision operations, governance and reporting.
- 01Administrator
- 02Prioritized decision queue
- 03Identity and access review
- 04Incident workflow
- 05Approval chain
- 06Reporting
Zone 5
KRYOS Decision Ledger
Every important decision becomes structured, visible and auditable.
Event
Evidence
Confidence
Recommendation
Authority
Action
Outcome
Edge and Console both write to the same record, so reporting and institutional learning draw on one shared history.
Step 1 of 9
Existing security tools stay in place and keep running.
Selected component
Hypercube decision engine
Evidence is evaluated across several dimensions at once: cross-verification, competing explanations, risk and consequence, confidence and uncertainty, policy and authority. The output is a decision with a recommended action, not a raw score.
Scenario simulator · illustrative mock data
See Edge and Console Work Together
Choose a scenario and follow the decision from the employee’s browser to centralized governance and the permanent Decision Ledger. Every step is written out in full text below the diagram, so the sequence can be read without playing it.
Each scenario moves through four participants in order: KRYOS-XS Edge in the employee’s browser, the Hypercube decision engine, KRYOS-XS Console for centralized governance, and the Decision Ledger, which stores the permanent record. Use the Previous and Next buttons to move one step at a time.
A suspicious credential-reset message reaches an employee inbox.
Existing stack · evidence sources remain in place
- SIEM
- Identity Provider
- Endpoint Security
- Cloud Security
- Email Security
- Collaboration & File Sharing
Step 1 of 8
An employee receives a message requesting an urgent password reset.
Read every step of this scenario as text
Step 1 · KRYOS-XS Edge
User action
An employee receives a message requesting an urgent password reset.
Step 2 · KRYOS-XS Edge
Context capture
Edge captures the approved message context without monitoring unrelated browsing.
Step 3 · Hypercube
Evidence evaluation
Hypercube compares legitimate and malicious explanations.
Step 4 · KRYOS-XS Edge
Inline verdict
Edge returns a plain-language verdict inside the moment of action.
STOP — Strong evidence of credential harvesting.
Step 5 · KRYOS-XS Edge
User response
The dangerous action is prevented before credentials are exposed.
Step 6 · KRYOS-XS Console
Console governance
Console checks whether other employees received related messages and determines whether additional response is required.
Step 7 · KRYOS-XS Console
Organizational response
Console creates a prioritized decision for the authorized security administrator.
Step 8 · Decision Ledger
Decision Ledger
The organization retains a complete, auditable record of the decision.
Illustrative simulation using mock data. Names, files, recipients and records are examples only, not real people, customers or outcomes.
Edge and Console Solve Different Problems.
Two products, two stages, one shared decision record. Neither one repeats the work of the other.
Protection at the moment of action
KRYOS-XS Edge
- Works with individual employees
- Operates inside approved browser-based work surfaces
- Activates at defined moments of action
- Evaluates suspicious messages, external sharing and risky approvals
- Delivers an immediate inline verdict
- Helps prevent dangerous actions before they become incidents
- Sends the evidence and outcome to the Console
- Does not monitor unrelated browsing
Governance across the organization
KRYOS-XS Console
- Serves administrators, security teams and leadership
- Operates as a centralized decision hub
- Aggregates approved alerts and security evidence
- Prioritizes identity, access, data and incident decisions
- Coordinates investigation, approval and response
- Tracks decision ownership and deadlines
- Produces audit, framework, board and funder evidence
- Preserves organizational decision history
One Continuous Decision Lifecycle.
Edge protects the person while they work. Console remembers and governs every important decision.
When Edge evaluates an action, the event, evidence, verdict and user response are automatically sent to the Console. The Console gives authorized teams visibility into what occurred, determines whether additional action is required and preserves the complete decision in the KRYOS Decision Ledger.
This creates a continuous relationship between decentralized protection and centralized governance.
01
User Action
02
Edge Intervention
03
Hypercube Decision
04
User Response
05
Console Governance
06
Decision Ledger
07
Reporting and Learning
Enterprise-Grade Decision Support Without Enterprise-Scale Complexity.
By dividing responsibility between Edge and Console, KRYOS-XS gives mission-critical organizations a practical way to strengthen security without building a massive security operations center.
Employees receive clear guidance while they work. Administrators receive organized decisions instead of another wall of alerts. Leadership receives evidence of what occurred, what was decided and how the organization responded.
Who gets what
- Employees: clear guidance at the moment of action.
- Administrators: organized decisions with owners and deadlines.
- Leadership and funders: evidence of what occurred and how it was resolved.
Deployment scope today: Edge runs inside approved Google Workspace browser surfaces, and Console governs the approved signals those and other connected Workspace services provide. Connectors for other SIEM, identity, endpoint and cloud-security platforms are described as planned integrations and are scoped per grant deployment rather than enabled by default.
KRYOS-XS does not add another layer of noise. It creates the decision layer that connects the security environment.
KRYOS Decision Ledger
Every Security Decision. Evidenced. Authorized. Verifiable.
The KRYOS Decision Ledger connects real-time user protection with centralized governance by preserving the complete lifecycle of every consequential cybersecurity decision.
The KRYOS Decision Ledger is the continuous record-keeping backbone of the KRYOS-XS platform.
KRYOS-XS Edge helps employees make safer decisions at the moment of action. KRYOS-XS Console gives authorized teams centralized governance and response coordination. The Decision Ledger connects them by preserving what happened, what evidence was examined, what KRYOS recommended, who had authority, what action was taken and whether the outcome was verified.
Instead of recording only a generic “allowed” or “blocked” event, the Ledger preserves the complete reasoning and governance history behind the decision.
Captured Automatically at the Moment of Consequence
When Edge or Console evaluates an important security action, KRYOS creates a structured decision record.
The record begins when a consequential event is detected, for example a suspicious email, an external file-sharing request, a privileged-access change or an application requesting organizational data.
As the decision progresses, the Ledger records each material stage:
- 01The event or action detected
- 02The evidence collected
- 03The explanations evaluated
- 04The confidence and uncertainty identified
- 05The applicable policy
- 06The recommendation delivered
- 07The authority or approval required
- 08The action selected
- 09The execution result
- 10The final verified outcome
Why it matters
This creates continuity between a split-second browser decision and the organization’s long-term security governance.
More Than an Event Log
A conventional security log may show that something was allowed, blocked or changed. The KRYOS Decision Ledger is designed to explain why the decision occurred and whether the response was justified.
Anatomy of a KRYOS Decision Record
Decision ContextWhat was being decided, for whom and when.
- Exact security question
- Triggering event
- Affected user, file, account, application or system
- Date, time and source
EvidenceWhat was examined, where it came from and what was missing.
- Evidence examined
- Source of each evidence item
- Evidence timestamp and freshness
- Supporting and contradictory information
- Missing information
AnalysisCompeting explanations, consequence and confidence.
- Safe explanation
- Dangerous explanation
- Likelihood and potential consequence
- Confidence and uncertainty
- Insufficient or contradictory evidence, which routes the decision to human escalation instead of an automated verdict
- Applicable organizational policy
GovernanceWho had authority and what approval was required.
- Recommended action
- Alternative actions
- Required decision-maker
- Human approval
- Separation of duties where applicable
- Rollback requirement
OutcomeWhat was done and whether it was verified.
- Action selected
- Execution status
- Verified result
- Override or exception reason
- Later correction
- Final closure status
A Tamper-Evident History of Responsible Decisions
The Decision Ledger is designed to preserve an append-only, tamper-evident history of material security decisions.
Existing records should not be silently overwritten. If evidence changes, an action is reversed or a conclusion is corrected, KRYOS adds a linked update that preserves both the original decision and the later correction.
When supported by the deployed architecture, cryptographic integrity checks, controlled access, timestamped events and complete administrative auditing can help demonstrate whether a decision record has been altered.
Design properties
- Tamper-evident
- Append-only by design
- Version-preserving
- Audit-ready
- Verifiable decision history
Design properties are described as architectural intent. Which integrity controls are active depends on the deployment configuration agreed during onboarding, and each is confirmed in writing before it is relied on for compliance evidence.
From Decision History to Organizational Intelligence
Once consequential decisions are preserved, the Console can transform approved Ledger data into useful institutional outputs. Downstream reuse is gated: an authorized reviewer must approve the purpose, and privacy and data-minimization controls remove identifiers and file contents before anything leaves the Ledger.
Board and Funder Reporting
Summarize material events, decisions made, exposures corrected, response performance and unresolved risks.
Framework and Control Evidence
Connect actual decisions and completed actions to relevant organizational controls and cybersecurity frameworks.
Contextual Security Training
Convert approved and appropriately anonymized decisions into training based on the organization’s real threat patterns and common mistakes.
Continuous Improvement
Identify repeated risks, frequent overrides, delayed approvals, missing evidence and decision patterns that require policy or workflow improvement.
Governed flow · illustrative mock data
One governed source. Authorized uses only.
Approved Ledger records can reduce administrative work, strengthen reporting and turn real security decisions into practical organizational learning. Nothing reaches an output without passing the governance layer first.
Stage 1 of 8
Ledger entries appear
Closed decision records accumulate across categories. Each one already carries evidence, decision, authority, action and outcome.
Decision Ledger entries
Suspicious Email
Evidence · Decision · Authority · Action · Outcome
External File Sharing
Evidence · Decision · Authority · Action · Outcome
Account Risk
Evidence · Decision · Authority · Action · Outcome
Privileged Access
Evidence · Decision · Authority · Action · Outcome
OAuth Approval
Evidence · Decision · Authority · Action · Outcome
Incident Response
Evidence · Decision · Authority · Action · Outcome
Authorization, Privacy and Data-Minimization Controls
- Authorized purpose
- Role-based access
- Data minimization
- Anonymization
- Retention policy
- Sensitive-field removal
- Approval for training use
Awaiting minimization
Every record passes through this layer. No entry reaches an output directly.
Authorized outputs
Lessons returned to authorized administrators
Aggregated patterns are prepared for human review.
Selected output
Board Security Report
Aggregated, approved decision history prepared for board oversight.
Source fields used
- Decision category
- Verdict
- Authority level applied
- Action taken
- Verified outcome
- Time to resolution (mock value)
Fields excluded
- Individual identities
- File contents
- Message bodies
- Recipient addresses
- System credentials
Required authorization
Board reporting role, approved reporting period, aggregated view only.
Resulting output
- Material security events (mock value)
- Decisions completed (mock value)
- Risks requiring leadership attention
- Response performance (qualitative placeholder)
- Outstanding governance gaps
All figures shown are demonstration placeholders, not measured customer results.
Read this flow as text
- Stage 1 Ledger entries appear. Closed decision records accumulate across categories. Each one already carries evidence, decision, authority, action and outcome.
- Stage 2 Entries pass through governance controls. No record reaches a downstream use directly. Every entry is routed through authorization, privacy and data-minimization controls.
- Stage 3 Approved fields are selected. Only the fields permitted for the authorized purpose are carried forward.
- Stage 4 Sensitive fields are removed or anonymized. Identities, contents and confidential details are stripped or anonymized before anything leaves the governance layer.
- Stage 5 Authorized outputs activate. Each output receives only what its authorization permits, and nothing more.
- Stage 6 Reporting, training and framework evidence are generated. Board and funder reporting, control evidence and anonymized training material are produced from the same governed source.
- Stage 7 Aggregated lessons return to authorized administrators. Recurring patterns, overrides, delays and missing evidence are summarized for the people accountable for policy.
- Stage 8 Administrators decide whether policy or training should change. Every proposed change is reviewed and authorized by a person. KRYOS does not modify security policy on its own.
- Board Security Report: Aggregated, approved decision history prepared for board oversight. Source fields: Decision category, Verdict, Authority level applied, Action taken, Verified outcome, Time to resolution (mock value). Excluded: Individual identities, File contents, Message bodies, Recipient addresses, System credentials. Authorization: Board reporting role, approved reporting period, aggregated view only.
- Funder Impact Report: Program-level security progress, without sensitive incident detail. Source fields: Decision category counts (mock value), Corrective actions completed, Capacity milestones, Grant activity status. Excluded: Incident narratives, Affected systems or accounts, Staff identities, Beneficiary or partner data, Unresolved live investigations. Authorization: Explicit organizational approval per report. Nothing is disclosed automatically.
- Framework and Control Evidence: Supports evidence collection and control demonstration. Source fields: Decision records with completed actions, Approval and separation-of-duties records, Verification results, Policy applied at decision time. Excluded: Raw evidence artifacts, Personal data not required for control demonstration. Authorization: Compliance or governance role, scoped to the control set under review.
- Training From Approved, Anonymized Decisions: One approved decision becomes a short, contextual training card. Source fields: Decision pattern and category, Anonymized evidence themes, Recommended action, Verified outcome. Excluded: User identities, File names and contents, Operational locations, Confidential incident details, Partner or recipient identities. Authorization: Separate approval for training use, applied before any record enters a training set.
- Policy and Workflow Improvement: Patterns return to authorized administrators as review candidates. Source fields: Override frequency (mock value), Approval latency (mock value), Missing-evidence patterns, Repeated decision categories. Excluded: Individual performance profiling, Identifiable user attribution. Authorization: Authorized administrators review every proposed change. Nothing changes automatically.
One Decision, Preserved From Beginning to End
01
Action Detected
02
Evidence Collected
03
Analysis Completed
04
Verdict Delivered
05
Authority Confirmed
06
Action Taken
07
Outcome Verified
08
Decision Preserved
Decision Ledger flow · illustrative mock data
How a Security Decision Becomes a Verifiable Record
Follow one consequential action from the moment it is detected to the moment it is preserved. Select any zone for a short explanation, or step through the sequence manually. Every stage is written out in full below the diagram, so nothing depends on motion.
Stage 1 of 11 · Decision Sources
Sources stand ready
Edge watches approved moments of action. Console watches centralized security and administrative decisions. Neither has been triggered yet.
KRYOS-XS Edge
- Suspicious email
- External sharing
- OAuth approval
- Risky browser action
KRYOS-XS Console
- Account risk
- Privileged access
- Security alert
- Incident workflow
- Administrative decision
- Event context
- User or system
- Source
- Timestamp
- Relevant history
- Supporting evidence
- Contradictory evidence
- Missing evidence
- Organizational policy
Structured evidence package
- Cross-verification
- Safe explanation
- Dangerous explanation
- Confidence
- Uncertainty
- Consequence
- Policy
- Authority
- Recommended action
- Verdict
- —
- Evidence summary
- —
- Confidence
- —
- Required approver
- —
- Recommended action
- —
- Alternatives
- —
- Rollback requirement
- —
- Human approval
- Action selected
- Action executed
- Outcome verified
- 01DETECTED
- 02EVIDENCE CAPTURED
- 03ANALYSIS COMPLETED
- 04VERDICT ISSUED
- 05APPROVAL RECORDED
- 06ACTION TAKEN
- 07OUTCOME VERIFIED
- 08DECISION CLOSED
Every material stage is preserved as part of the decision history.
- Board Report
- Funder Report
- Framework Evidence
- Security Training
- Policy Improvement
- Risk Metrics
Consequential Decision Detected
Decision Sources
Edge recognizes a consequential moment inside approved browser work surfaces. Console recognizes one inside centralized security and administrative workflows. Either origin opens the same governed decision.
Read the full sequence as text
- 01 Sources stand ready. Edge watches approved moments of action. Console watches centralized security and administrative decisions. Neither has been triggered yet.
- 02 A consequential action occurs. In this illustrative run, an employee attempts to share a sensitive file with an external recipient. Edge recognizes a consequential decision point.
- 03 Evidence is gathered. Context, identity, source, timing, history, supporting and contradictory information, gaps and applicable policy are collected as discrete evidence objects.
- 04 Evidence is structured. The objects converge into one structured evidence package with the source and freshness of each item retained.
- 05 Hypercube evaluates the package. The package enters the decision engine. Safe and dangerous explanations are tested against the same evidence, and confidence, uncertainty and consequence are stated explicitly.
- 06 A verdict and authority requirement are created. A governed decision object is produced: verdict, evidence summary, confidence, required approver, recommended action, alternatives and rollback requirement.
- 07 An authorized person selects the action. The named approver reviews the decision object and selects an action. Authority is recorded with the choice.
- 08 The action is executed and verified. The selected action is carried out through the systems that own it, and the resulting state is verified rather than assumed.
- 09 The decision is closed and preserved. Every material stage now sits in the Ledger in order. The record is closed, and nothing recorded earlier has been rewritten.
- 10 A later correction is appended. New evidence arrives after closure. KRYOS appends a linked correction. The original entries remain visible beside it rather than being replaced.
- 11 Authorized downstream uses activate. Approved Ledger data flows into reporting, framework evidence, training, policy improvement and risk metrics. One record, several authorized uses.
Demonstration Scenario: Mock Data Only
Inside a KRYOS Decision Record
Follow a mock external file-sharing decision from the employee's browser to its final, verifiable organizational record.
- Decision ID
- KX-DEMO-DS-00417
- User
- Authorized User A
- File
- Project-Brief.pdf
- Recipient
- partner-example.org
- Requested action
- External view access
Step 1 of 9 · Ledger event: DETECTED
Decision created
Edge detects the consequential action before external access is finalized.
Ledger events
- 01DETECTED
Events append in order. Nothing already written is replaced.
- Decision question
- Should Authorized User A share Project-Brief.pdf with an external recipient?
- Trigger source
- KRYOS-XS Edge
- Action state
- Not yet completed
This part of the record has not been written yet in the scenario. Step forward to see it.
This part of the record has not been written yet in the scenario. Step forward to see it.
This part of the record has not been written yet in the scenario. Step forward to see it.
This part of the record has not been written yet in the scenario. Step forward to see it.
This part of the record has not been written yet in the scenario. Step forward to see it.
This part of the record has not been written yet in the scenario. Step forward to see it.
CORRECTION ADDED: Access revoked after project completion.
- Reason for correction
- Project completed; external collaboration window closed.
- New action
- External view access revoked; recipient permission removed.
- Linked to
- KX-DEMO-DS-00417, original approval preserved
- Original record
- Remains visible and unchanged above this entry.
Read the complete mock decision record as text
Step 1 · DETECTED
Decision created
- Decision question: Should Authorized User A share Project-Brief.pdf with an external recipient?
- Trigger source: KRYOS-XS Edge
- Action state: Not yet completed
Step 2 · CONTEXT RECORDED
Context captured
- User: Authorized User A
- File: Project-Brief.pdf
- Recipient: partner-example.org
- Requested permission: External view access
- Application: Approved document workspace (demo)
- Timestamp: Demonstration value
- Existing sharing state: Internal access only
Step 3 · EVIDENCE CAPTURED
Evidence collected
- Recipient is outside the organization: Source: directory boundary check (Observed: demonstration value)
- File carries an internal sensitivity label: Source: document classification label (Observed: demonstration value)
- User has permission to request sharing: Source: workspace permission model (Observed: demonstration value)
- Recipient belongs to a known partner domain: Source: organizational partner list (Observed: demonstration value)
- Existing policy requires approval for this file category: Source: organizational sharing policy (Observed: demonstration value)
- No existing approval is attached: Source: approval records (Observed: demonstration value)
Step 4 · ANALYSIS COMPLETED
Alternatives evaluated
- Safe explanation: The recipient is a legitimate project partner with a valid operational need.
- Dangerous explanation: The requested permission may expose sensitive information beyond the approved audience.
- Contradictory or balancing evidence: Partner relationship is legitimate, but the file's sensitivity requires additional authority.
- Missing evidence: Named approver confirmation has not yet been received.
Step 5 · VERDICT ISSUED
Verdict issued
- Verdict: APPROVAL REQUIRED
- Rationale: The relationship appears legitimate, but organizational policy requires approval before this file category can be shared externally.
- Recommended action: Request approval and use restricted view access.
- Alternative: Share an approved redacted version.
- Confidence: High (demonstration value) (Mock scenario data, not a live score)
Step 6 · APPROVAL REQUESTED
Authority confirmed
- Required approver: Program Security Owner
- Separation of duties: Requester cannot self-approve.
- Deadline: Demonstration value
- Rollback requirement: External permission must be removable immediately.
Step 7 · APPROVAL RECORDED
Action selected
- Decision: Approved with restrictions
- Approver: Authorized Approver B
- Condition: View access only
- Condition: Named recipient only
- Condition: No public link
- Condition: Time-limited access
- Condition: Access review required
Step 8 · OUTCOME VERIFIED
Outcome verified
- External access created: Confirmed
- Permission matches approved role: Confirmed
- Public-link access remains disabled: Confirmed
- Named recipient confirmed: Confirmed
- Expiration condition recorded: Confirmed
- No unauthorized recipient detected: Confirmed
Step 9 · DECISION CLOSED
Decision closed
- Decision ID: KX-DEMO-DS-00417
- Trigger: KRYOS-XS Edge, external sharing request
- Evidence: Six items captured with source and observation time
- Analysis: Safe and dangerous explanations compared; missing evidence noted
- Verdict: APPROVAL REQUIRED
- Approver: Authorized Approver B
- Action: Approved with restrictions: restricted external view access
- Verification: Implemented permission matched the approved decision
- Linked audit events: Eight appended ledger events in sequence
- Integrity status: Append-only by design; cryptographic verification depends on the deployed architecture
- Final status: Closed: Approved Restrictive Sharing Verified
Traditional log: File shared.
KRYOS Decision Ledger: What was requested, what evidence was examined, why approval was required, who authorized it, what restrictions were applied and whether the final access matched the approved decision.
Edge protects the person. Console governs the organization. The Decision Ledger preserves the truth of what happened between them.
The overlay
A Non-Intrusive Layer Above the Security Stack You Already Run
Follow evidence from your existing systems through reasoning, simulation, and governance, and back to the controls that enforce the approved action.
KRYOS-XS Non-Intrusive Cybersecurity Overlay
Identity, security operations, endpoint, network, cloud, data, exposure, and intelligence systems continue collecting telemetry and enforcing controls.
- Nothing is removed and no agent is installed.
- Each product keeps its own console, policy, and enforcement role.
- The organization selects which systems may participate.
Your existing cybersecurity stack
Identity, security operations, endpoint, network, cloud, data, exposure, and intelligence systems continue collecting telemetry and enforcing controls.
- Nothing is removed and no agent is installed.
- Each product keeps its own console, policy, and enforcement role.
- The organization selects which systems may participate.
Public architecture view. Internal processing inside KRYOS-XS is not shown.
Delivery boundary
Supported and Excluded
The overlay is API-only. These lists define exactly what it can and cannot observe or do.
- Evidence before inference.
- Authority before action.
- Verification before assurance.
Supported
What ArtOfTheHack uses
- Approved work surfaces and authorized APIs
- Inline decision support at the moment of action
- Cross-source correlation of available evidence
- Explainable recommendations with confidence and uncertainty
- Approval-gated action in the organization's own systems
- Complete decision logging in the KRYOS Decision Ledger
- Outcome verification and board-ready reporting
Excluded
What ArtOfTheHack never uses
- Replacement of existing security products
- Unrelated personal browsing collection
- Endpoint agents, appliances or packet capture
- Independent malware detection
- Hidden or unsupported data access
- Autonomous consequential action
- Claims a connected system cannot evidence
KRYOS does not claim evidence that a connected system cannot provide. When data is incomplete, the platform identifies the limitation and requests the appropriate human or technical input.
Stage 01
Your Existing Cybersecurity Stack Stays in Place
Your existing security systems continue collecting telemetry and enforcing controls.
Identity
- Identity Provider
- IAM
- PAM
- ZTNA
Security Operations
- SIEM
- XDR
- SOAR
Endpoint and Network
- EDR
- NDR
- Firewall
- NAC
Cloud and Application
- Cloud Security
- CNAPP
- API Gateway
- Workload Security
Data
- DLP
- DSPM
- Sensitive Data Repositories
Exposure
- Vulnerability Management
- Asset Inventory
- CMDB
Intelligence
- Threat Intelligence
- Internal Telemetry
Stage 02
Connection Happens Through Scoped, Revocable Interfaces
The participating organization determines which systems may connect, which evidence is available, and whether any write authority is granted.
Connection methods
- REST API
- Signed Webhook
- Event Stream
- Syslog
- OTLP
- TAXII and STIX
- Secure Batch
- Private Connector
- Read-first
- Scoped
- Revocable
Read-first
Initial deployment normally begins without production write authority.
Minimum necessary access
Only information needed for the approved cybersecurity workflow should be connected.
Revocable connections
The organization can independently revoke integration credentials.
Native enforcement
Existing cybersecurity products remain the control points.
Native fallback
If KRYOS-XS is unavailable, existing security systems continue to operate.
Kill switch
Authorized automated paths can be halted without disabling the underlying security architecture.
Stage 03
Evidence From Different Systems Becomes Decision-Grade
Signals collected by separate products rarely agree on entities, timing, or meaning. Before anything influences a decision, that disagreement is made explicit rather than averaged away.
- Normalization
- Entity Resolution
- Temporal Alignment
- Provenance
- Freshness
- Evidence Quality
- Source Independence
- Contradiction Identification
- Relationship Mapping
- Cryptographic Integrity
Conflicting evidence retained
- Identity SystemAuthentication succeeded.Supported
- Endpoint SecurityNo malicious process observed.Contradicted
- Network SecuritySession source is unusual.Unresolved
- Data SecurityUnusual bulk-access request.Unresolved
- Threat IntelligenceRelevant credential-theft activity is active.Additional Evidence Needed
Stage 04
Reasoning Across Interacting Cybersecurity Dimensions
A single signal rarely determines what should happen. KRYOS-XS Hypercube evaluates how conditions relate to one another, which is why a decision can change when only the surrounding context changes.
- Identity
- System State
- Privilege
- Network Context
- Cloud Context
- Data Sensitivity
- Exposure
- Threat Conditions
- Mission Impact
- Control Effectiveness
- Policy
- Authority
- Time
- Reversibility
- Confidence
- Uncertainty
Representative cybersecurity dimensions. Internal modeling and decision mechanics remain proprietary.
Stage 05
Competing Interpretations Are Tested, Not Assumed Away
The same evidence usually supports more than one explanation. Each candidate explanation is carried forward with its own standing until the evidence justifies narrowing.
- Legitimate user in unusual circumstancesSupported
- Credential compromiseUnresolved
- Compromised endpointContradicted
- Unauthorized privilege changeAdditional Evidence Needed
- Unexpected but authorized workUnresolved
Interpretations remain open until the evidence justifies a narrower conclusion.
Defensive challenge
A proposed conclusion is deliberately challenged before it becomes a decision. The analysis asks whether:
- The dominant explanation is incomplete
- Another attack path remains plausible
- Trusted telemetry may be stale
- A control has hidden dependencies
- The proposed response produces unnecessary disruption
- Alternative evidence changes the conclusion
- An attacker could benefit from an assumption made by the defensive team
ArtOfTheHack performs authorized defensive analysis and simulation only. It does not provide unauthorized intrusion, credential theft, malware deployment, exploit execution, or offensive attacks against third parties.
Stage 06
Consequence Is Modeled Before Production Changes Occur
A Cyber Digital Twin represents the relationships between identities, systems, data, privileges, controls, and mission-critical functions so a candidate response can be examined before it touches the live environment.
| Response option | Risk reduction | Disruption | Reversibility | Residual risk | Confidence | Blast radius |
|---|---|---|---|---|---|---|
| Monitor | Low | Low | High | High | Moderate | Low |
| Revoke identity | High | High | Moderate | Low | Moderate | High |
| Isolate endpoint | High | High | Moderate | Low | Moderate | Moderate |
| Restrict session and step-up authentication | Moderate | Low | High | Moderate | Moderate | Low |
Modeled comparison. Not recipient telemetry and not a guarantee of outcome.
Advanced Monte Carlo and probabilistic scenario methods may be selected according to the approved workflow and available evidence.
Stage 07
Evidence Does Not Become Action. It Becomes a Governed Decision.
The governed decision is the reviewable object that carries interpretation, evidence, recommended control, required authority, validity, rollback, and provenance.
- Decision
- Allow with constraints
- Risk
- Moderate
- Confidence
- Moderate
- Uncertainty
- Retained and reported
- Primary Interpretation
- Legitimate work from an unusual location
- Alternative Interpretations
- Credential compromise, compromised session
- Supporting Evidence
- Known device, working hours, successful authentication
- Contradictory Evidence
- Unusual network context, bulk-access request
- Recommended Control
- Stronger authentication and session restriction
- Required Authority
- Named approver for data-access constraints
- Approval Status
- Awaiting named approval
- Validity
- Short validity period
- Rollback
- Constraint can be lifted by the approver
- Provenance
- Hash-linked evidence and decision record
- Outcome
- Returned for calibration after execution
Public conceptual representation. Internal decision schemas and release logic remain proprietary.
Stage 09
The Observed Outcome Returns for Calibration
A decision system that never compares its interpretation with what actually happened cannot improve. Outcome evidence returns to the reasoning layer for review.
Questions asked after execution
- Was the interpretation correct?
- Did the control reduce risk?
- Did the response cause unnecessary disruption?
- Was the recommendation overridden?
- Was rollback required?
- Did the incident recur?
- Which evidence proved useful?
- Which evidence proved misleading?
Comparison
Before the Overlay and After the Overlay
Nothing is removed. What changes is how evidence from those systems is adjudicated and how the resulting action is authorized.
Without KRYOS-XS
- Separate telemetry
- Separate dashboards
- Vendor-specific conclusions
- Duplicate alerts
- Manual correlation
- Conflicting signals
- Static severity
- Response playbooks
- Implicit authority
- Incomplete decision history
With KRYOS-XS
- Normalized evidence
- Cross-system relationships
- Contradictions retained
- Competing interpretations
- Multidimensional context
- Scenario comparison
- Mission consequence
- Explicit authority
- Reversible control
- Governed decision record
- Outcome calibration
Ecosystem
How the Overlay Relates to Established Security Categories
Each category keeps its existing role. The overlay contributes adjudication, context, consequence, and governance above it.
| Category | Existing role | What the overlay contributes |
|---|---|---|
| Identity, IAM, PAM, ZTNA | Authentication and access enforcement. | Adds broader contextual evidence when a consequential or contested access decision requires more than static role evaluation. |
| SIEM | Collect and correlate telemetry. | Provides higher-order evidence adjudication, contradiction analysis, competing interpretations, and contextual decision support. |
| XDR | Cross-domain detection and investigation. | Allows XDR findings to be evaluated alongside external identity, cloud, vulnerability, data, policy, and organizational context. |
| SOAR | Execute playbooks. | Supports governed selection among response options before an approved playbook executes. |
| EDR and NDR | Endpoint and network detection and response. | Evaluates how endpoint and network observations relate to the broader incident and possible containment consequences. |
| Cloud Security and CNAPP | Cloud posture, entitlement, exposure, and runtime security. | Adds identity paths, data sensitivity, threat evidence, operational consequence, and response comparison. |
| Vulnerability Management | Identify weaknesses. | Adds reachability, attack paths, identity context, mission importance, active threat evidence, compensating controls, and remediation consequence. |
| Threat Intelligence | Provide threat information. | Evaluates freshness, relevance, independence, corroboration, contradiction, and local applicability before intelligence influences a decision. |
| DLP and DSPM | Discover and control sensitive information. | Adds identity, purpose, application, destination, context, behavior, policy, and mission need when evaluating data movement. |
| ITSM and Ticketing | Changes, incidents, approvals, and institutional workflow. | Treats legitimate change, ownership, approval, and organizational context as cybersecurity evidence and routes decisions back into existing workflows. |
The overlay architecture is designed to work with mainstream security ecosystems such as Microsoft security platforms, Palo Alto Networks, CrowdStrike, Splunk, Google Security Operations, Okta, CyberArk, Zscaler, Tenable, Wiz, ServiceNow, and comparable API-capable systems. These are examples of technology categories with which an overlay architecture may integrate, not partnerships, certifications, or endorsements.
Mission environment
What This Means for Nonprofits, NGOs, Think Tanks, and Institutes
Mission organizations run modern, distributed environments while carrying targeted risk and limited security staffing. The overlay adds decision capacity rather than another product to operate.
Typical environment
- Cloud collaboration
- Remote staff
- Field teams
- Donor systems
- Beneficiary records
- Policy research
- Intellectual property
- Sensitive communications
- Public websites
- External IT providers
- SaaS platforms
- Mobile devices
- Partner organizations
Questions the overlay is built to answer
- Should this user have access to these beneficiary records right now?
- Does this vulnerability create a plausible path to sensitive research?
- Are these five security alerts one incident or several unrelated events?
- Will isolating this endpoint interrupt a mission-critical program?
- Does the evidence justify revoking a privileged administrator?
- Should this unusual data movement be blocked, constrained, or reviewed?
- Is a threat-intelligence assertion sufficiently reliable to change access policy?
- Which response reduces risk without unnecessarily interrupting the mission?
Illustrative nonprofit cybersecurity scenario
One Access Request, Step by Step
A program director attempts to access a sensitive cloud repository containing beneficiary records.
What the systems observe
- Authentication succeeds.
- The device is known.
- Network context is unusual.
- Device telemetry is not completely current.
- A bulk-access request differs from normal behavior.
- Relevant credential-theft activity has been reported in the sector.
- No malicious process is observed on the registered endpoint.
- The request occurs during legitimate working hours.
Interpretations held open
- Legitimate work from an unusual location
- Credential compromise
- Compromised session
- Unexpected but legitimate operational requirement
Response options compared
- Full denial
- Credential revocation
- Endpoint isolation
- Stronger authentication
- Restricted session
- Temporary bulk-export restriction
- Human review
Governed outcome
Allow with constraints
- Require stronger authentication.
- Permit limited record access.
- Temporarily restrict bulk export.
- Set a short validity period.
- Escalate if additional risk evidence appears.
Illustrative example only. Not recipient telemetry or a measured customer outcome.
The objective is not the most aggressive cybersecurity response. The objective is the least-disruptive defensible response supported by the available evidence, permitted by policy, and authorized by the organization.
Grant funded
Delivered at No Cost Through Grant-Funded Cybersecurity Work
Approved organizations receive the technology and the implementation work required to use it, funded by James Scott and managed by the Embassy Row Project.
Work covered by the grant
- Cybersecurity architecture assessment
- Existing-system mapping
- API integration
- Evidence-source configuration
- KRYOS-XS overlay setup
- Read-only shadow evaluation
- Cybersecurity decision workflows
- Cyber Digital Twin configuration
- Scenario simulation
- Defensive stress testing
- Policy and authority configuration
- Decision audit
- Outcome review
- Technical support
Grant conditions
- Approved services are provided at no cost within the authorized grant scope.
- The grant provides cybersecurity technology and services.
- It is not an unrestricted cash award.
- Application does not guarantee approval.
Direct answers
Questions Security Leaders Ask
Short, quotable answers for evaluators, boards, funders, and retrieval systems.
- What is KRYOS-XS Hypercube?
- KRYOS-XS Hypercube is the cybersecurity reasoning and governance technology underlying ArtOfTheHack. It connects to approved cybersecurity systems through narrowly scoped, revocable interfaces, evaluates their combined evidence, challenges conflicting interpretations, models response consequences, applies policy and authority constraints, and produces a governed cybersecurity decision without replacing the security controls already in operation.
- How does KRYOS-XS work?
- Approved security systems connect through scoped, revocable interfaces. Their evidence is reconciled into decision-grade form, evaluated across interacting cybersecurity dimensions, tested against competing interpretations and defensive challenge, and modeled for response consequence. The result is a governed decision that policy and named human authority release to the security controls already in place, after which the observed outcome returns for calibration.
- Is KRYOS-XS a SIEM?
- No. A SIEM collects and correlates telemetry. KRYOS-XS sits above collection and evaluates what the combined evidence means, which interpretations remain open, what a candidate response would cost operationally, and who is authorized to approve it.
- Does KRYOS-XS replace CrowdStrike, Microsoft, Palo Alto, Splunk, or other cybersecurity tools?
- No. KRYOS-XS is designed to work above API-capable security products and return governed decisions to them. Those products remain the enforcement points and continue to operate if the overlay is disconnected.
- What is a cybersecurity API overlay?
- An overlay is a reasoning and governance layer that connects to existing security systems through their interfaces rather than sitting inline in the enforcement path. It reads evidence, produces decisions, and returns authorized instructions to the native controls.
- What does non-intrusive mean?
- No agent is installed, no appliance is placed in the network path, and no existing product is replaced. Deployment normally begins read-first, access is limited to what the approved workflow requires, and the organization can revoke the integration credentials on its own.
- What is a governed cybersecurity decision?
- It is a reviewable decision record that carries the decision itself along with risk, confidence, retained uncertainty, the primary and alternative interpretations, supporting and contradictory evidence, the recommended control, the required authority, approval status, validity, rollback, provenance, and the observed outcome.
- How does KRYOS-XS use Cyber Digital Twins?
- A Cyber Digital Twin can represent relevant identities, devices, applications, cloud services, data, privileges, dependencies, controls, and mission-critical functions so candidate responses can be compared before production systems change.
- How does KRYOS-XS use Monte Carlo simulation?
- Probabilistic scenario simulation can examine how plausible combinations of attacker behavior, detection timing, control performance, staff response, backup availability, and hidden dependencies change the range of plausible consequences. It evaluates plausible scenarios rather than predicting a single future.
- What is defensive red-team reasoning?
- It is authorized defensive challenge applied to the proposed conclusion before release, asking whether the dominant explanation is incomplete, whether another path remains plausible, whether telemetry is stale, and whether the response creates unnecessary disruption. It never involves unauthorized intrusion or exploit execution.
- What is cryptographic provenance?
- Material evidence and decision artifacts can carry source, timestamp, version, lineage, approval, and integrity information. Hash-linked, tamper-evident records support independent verification and later review.
- Who retains authority?
- The participating organization. It defines which actions are permitted, who may approve them, which decisions require additional review, and which action classes may ever run automatically. Unrestricted autonomous remediation is not the objective.
- What happens if KRYOS-XS is unavailable?
- The existing security systems continue to operate exactly as before. The overlay is not in the enforcement path, and authorized automated paths can be halted with a kill switch without disabling the underlying security architecture.
- Who can access ArtOfTheHack?
- Eligible nonprofit organizations, NGOs, think tanks, foundations, humanitarian organizations, and nonprofit institutes may apply through the ArtOfTheHack cybersecurity grant program.
- Who funds the cybersecurity grants?
- The grants are funded by James Scott.
- Who manages the grant program?
- The grant program is managed by the Embassy Row Project.
Public architecture materials describe the role, integration boundaries, governance principles, and functional capabilities of KRYOS-XS Hypercube. Proprietary algorithms, internal model configurations, scoring methodologies, prompts, private schemas, implementation logic, and security configurations are not published.
Next step
Bring Governed Cybersecurity Decisions to Your Mission
Apply for a fully funded grant, or ask a technical question about connecting KRYOS-XS to the systems you already run.