Product 01 / 3 capabilities
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.
Open KRYOS-XS EdgeCybersecurity portfolio
Two Integrated Cybersecurity Products. Eleven Governed Decision Capabilities.
KRYOS-XS is a Cyber Decision Assurance Platform that converts cybersecurity evidence into safe, explainable, authorized and verifiable decisions.
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.
Operating model
A non-replacement cybersecurity intelligence layer
ArtOfTheHack does not install software inside the organization. It authorizes against existing platforms, reads the evidence those platforms already expose, reasons over it, and returns a governed decision. Any consequential action is executed by the source system's own API, only after a named human approves it.
What the platform 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
What the platform 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.
Shared operating model
Six stages, applied identically to every capability
The platform is one architecture applied to eleven different classes of security decision. The connectors and policies change. The sequence does not.
Stage 01
Authorize
Approved integration with the minimum scope the capability requires.
Stage 02
Detect
A consequential security action or signal is identified for evaluation.
Stage 03
Gather
Available evidence is retrieved from the connected systems and its source and age recorded.
Stage 04
Reason
The Hypercube Decision Engine cross-checks facts, compares safe and dangerous explanations and applies policy.
Stage 05
Authorize action
Required authority is confirmed and a named human approves anything consequential.
Stage 06
Verify and record
The outcome is verified and preserved in the KRYOS Decision Ledger.
Non-negotiable across every capability
- Read-only advisory operation by default
- Human approval for high-impact actions
- Least-privilege, revocable permissions
- Explicit blind spots instead of assumed facts
- Reversible enforcement wherever technically available
- Every action and outcome is verified against the source system
Operating principle
- Evidence before inference.
- Authority before action.
- Verification before assurance.
Launch product
KRYOS-XS Console is the flagship first product
A centralized Cyber Decision Operations Hub that converts alerts, identity risks, access questions, data exposures and response requirements into one prioritized decision queue.
The nonprofit pilot sequence
Days 1 to 5
Assess and Authorize
- Initial security assessment
- Least-privileged Workspace scopes
- Approved surface definition
Then Connect and Observe
Days 6 to 12
Connect and Observe
- Google Workspace connection
- Console decision queue populated
- No recommendations shown yet
Then Advisory Operation
Days 13 to 20
Advisory Operation
- Edge deployed to approved surfaces
- Inline verdicts delivered
- Administrator accept or reject rationale
Then Gated Action
Days 21 to 26
Gated Action
- Named human approval
- Low-complexity supported actions
- Before and after verification
Then Prove and Report
Days 27 to 30
Prove and Report
- Decision Ledger reconciliation
- Board and funder report
- Continue, modify or terminate
Continue, modify or end
The pilot begins read-only. No consequential API action is permitted without named human approval, and the organization can withdraw the credentials at any point.
Pre-registered pilot targets
These are proposed validation thresholds agreed before a pilot starts. They are success criteria to be measured, not results already achieved and not a guarantee of any outcome.
- Pilot target
- 95% or more
- Connected evidence coverage
- Pilot target
- 85% or more
- Validated sharing-finding precision
- Pilot target
- 90% or more
- Validated OAuth-finding precision
- Pilot target
- 50% or more
- Administrator review-time reduction
- Pilot target
- 80% or more
- Accepted or justified decisions
- Pilot target
- Zero
- Unauthorized changes or material disruption
Products
Two products, in delivery order
Edge decides at the moment of action inside approved work surfaces. The Console decides across the organization. Both run the same reasoning core, the same decision record, and the same governance rail.
Product 02 / 8 capabilities
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.
Open KRYOS-XS ConsoleService explorer
All 11 governed decision capabilities
Filter by product, expand any capability to read its six-stage sequence and hard boundary, or open the full service page.
Showing 11 of 11 governed capabilities across 2 of 2 products
Product 01 / 3 services
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.
Service 01
Suspicious Message Adjudication
Determine whether a message appears legitimate, unwanted or malicious, and present the recommendation beside the message.
- 01 DetectThe user opens or reports a suspicious message inside an approved mail surface.
- 02 GatherSender identity, message content, links, attachments and available email headers are collected with the application context.
- 03 Cross-checkImpersonation indicators, credential-harvesting patterns, organizational relationships, known threat intelligence and similar reported messages are compared.
- 04 EvaluateThe user or department being targeted is weighed against the competing safe explanation before any verdict is formed.
- 05 RecommendA clear verdict is presented inline: safe, treat cautiously, escalate for review, strong evidence of phishing, or additional evidence required.
- 06 RecordEvidence, verdict, user response and final outcome are sent to the Console and preserved in the Decision Ledger.
The message appears safeThe message should be treated cautiouslyThe message should be escalated for security reviewThe message shows strong evidence of phishing or credential theftAdditional evidence is required before a safe verdictBoundary. Edge evaluates messages on approved work surfaces only. It does not inspect unrelated personal mail, and it does not replace the organization's mail platform or email security gateway.
Open the Suspicious Message Adjudication service pageService 02
External Sharing and Data-Movement Governance
Evaluate a sharing decision before sensitive information leaves the organization, and offer a safer method.
- 01 DetectA user creates an external sharing link, adds an external recipient or widens a file permission.
- 02 GatherThe file or information being shared, the recipient identity and domain, and existing file permissions are identified.
- 03 Cross-checkInternal, external or public status, partner or coalition standing, previous sharing history and available data classifications are compared.
- 04 EvaluateOrganizational sensitivity rules, user authority and potential operational and mission consequences are applied.
- 05 RecommendA safer sharing method is offered where one exists: restrict the recipient list, remove public access, request approval or share through an approved partner group.
- 06 RecordThe evidence, verdict, user response and final outcome are preserved in the Decision Ledger.
Inline verdict with the reason statedA safer sharing method where one existsRestricted recipient list or removal of public accessApproval request routed to the required authorityPotential operational and mission consequenceBoundary. Edge acts on approved collaboration surfaces and authorized API evidence only. Enforcement remains with the organization's own platform, and the visible interface never substitutes for authoritative security state.
Open the External Sharing and Data-Movement Governance service pageService 03
Cloud Exposure and Configuration Decisioning
Identify configuration changes that may create unnecessary exposure, while the change is still being made.
- 01 DetectAn authorized user views or changes an important cloud configuration on an approved management console.
- 02 GatherThe visible interface supplies the action context; connected systems supply the authoritative security state through APIs.
- 03 Cross-checkPublic storage permissions, broad identity policies, open security-group rules and external access settings are compared against the current state.
- 04 EvaluateUnnecessary administrator access, risky authentication changes and misconfigured sharing controls are weighed for consequence and reversibility.
- 05 RecommendA verdict is returned inline, with approval required where the change exceeds the user's authority.
- 06 RecordThe configuration decision, its evidence and its outcome are preserved in the Decision Ledger.
Exposure created by the proposed changeInline verdict with required authorityRecommended safer configurationRollback requirementEscalation where evidence is insufficientBoundary. Edge combines the action a user is taking with authoritative API evidence when available. Where a connected system cannot evidence the configuration, the limitation is stated rather than inferred.
Open the Cloud Exposure and Configuration Decisioning service page
Product 02 / 8 services
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.
Service 04
Alert Triage and Incident Adjudication
Consolidate security alerts into a prioritized decision queue and connect related events so the broader situation is evaluated.
- 01 ConsolidateRelevant Google Workspace security alerts are gathered into one queue.
- 02 RelateRelated events are connected so isolated alerts are not reviewed individually.
- 03 Cross-checkEvidence source and age are verified and contradictory evidence is sought.
- 04 PrioritizeLikelihood and potential impact are estimated and organizational policy applied.
- 05 AssignAn owner, required approver, severity, deadline and recommended action are set.
- 06 VerifyThe outcome is confirmed and the decision preserved in the Decision Ledger.
PriorityOwnerSeverityConfidenceMissing informationRecommended actionRequired approverDeadlineCurrent statusBoundary. KRYOS does not create raw telemetry and does not detect. It organizes and adjudicates what connected systems already report.
Open the Alert Triage and Incident Adjudication service pageService 05
Account-Compromise Assessment
Distinguish legitimate unusual behavior from potential account compromise using available identity evidence.
- 01 DefineThe exact question is stated: is this account compromised, or behaving unusually for a legitimate reason.
- 02 GatherLogin location, device history and authentication events are collected.
- 03 ConnectAdministrative activity, file access and sharing activity are joined to the same identity.
- 04 CompareUser role, recent behavioral changes and related security alerts are weighed against the benign explanation.
- 05 RecommendA proportionate response is proposed with the required authority named.
- 06 VerifyAccount state is rechecked after the approved action and the outcome recorded.
Compromise likelihood with the competing explanation statedConfidence and uncertaintyMissing informationRecommended responseRequired approverVerified outcomeBoundary. Where evidence is insufficient, KRYOS escalates rather than creating false certainty. Enforcement runs in the organization's own identity platform.
Open the Account-Compromise Assessment service pageService 06
Access and Entitlement Review
Identify unnecessary, outdated or unusually powerful access and recommend what should change.
- 01 InventoryGroup memberships, organizational roles and administrator privileges are collected.
- 02 TraceThird-party and partner access is resolved to the effective entitlement it grants.
- 03 CompareDormant entitlements and access inconsistent with current responsibilities are identified.
- 04 EvaluatePotential impact of retaining or removing each entitlement is estimated.
- 05 CertifyThe named manager or data owner reviews and approves each recommendation.
- 06 VerifyEffective access is re-read after the approved change and the review recorded.
Retain, reduce, time-bound, transfer or revokeEvidence of needPotential impactRequired approverVerified outcomeBoundary. Only access exposed by a connected system can be reviewed. Access held on platforms without a supported API is stated as a coverage gap.
Open the Access and Entitlement Review service pageService 07
Privileged-Access Governance
Understand who holds administrative authority, why it exists, whether it remains necessary and what compromise would cost.
- 01 IdentifyAccounts holding administrative authority are enumerated from connected systems.
- 02 JustifyThe reason the authority exists is established and attached to a named owner.
- 03 TestWhether the authority remains necessary is checked against recent administrative activity.
- 04 ModelThe consequence of compromise for each privileged account is estimated.
- 05 ApproveThe system owner and security authority approve any reduction or removal.
- 06 VerifyPrivilege state and emergency continuity are confirmed after the change.
Necessity determinationBlast radius if compromisedLeast-privilege recommendationRequired approverRollback and emergency continuityBoundary. Privileged accounts absent from connected administrative APIs cannot be assessed. KRYOS does not replace an IAM or PAM platform.
Open the Privileged-Access Governance service pageService 08
External-Party Access Governance
Decide which external access should be retained, restricted, reviewed or revoked.
- 01 EnumerateAccess granted to vendors, consultants, coalition members and partner organizations is collected.
- 02 AttributeVolunteers, former employees and temporary personnel are matched to a sponsor and purpose.
- 03 Cross-checkCurrent employment or engagement status is compared against the access still held.
- 04 EvaluateThe data each external party can reach and the risk of persistence are assessed.
- 05 DecideRetain, restrict, review or revoke is routed to the sponsor and system authority.
- 06 VerifyThe change is confirmed and continued service or dependency impact is checked.
RetainRestrictReviewRevokeNamed sponsor and required approverBoundary. External access on systems that expose no API is out of scope and is reported as a gap rather than assumed to be absent.
Open the External-Party Access Governance service pageService 09
OAuth and Automation Authority Governance
Evaluate applications, integrations and automated agents requesting organizational access, before and after the grant.
- 01 CollectRequested permissions, publisher identity and application purpose are gathered.
- 02 AttributeThe user requesting access and the data potentially available are identified.
- 03 Cross-checkOrganizational necessity and existing alternatives are compared.
- 04 EvaluatePrevious activity and the risk created by persistent access are assessed.
- 05 DecideRetain, constrain, re-consent, suspend or revoke is routed to the required authority.
- 06 VerifyRevocation is confirmed and a documented reauthorization path is retained.
Access footprint of the applicationSpecific risk driversRecommended dispositionRequired approverRollback and reauthorization pathBoundary. Grants absent from connected administrative APIs cannot be assessed, and no secret or token material is collected.
Open the OAuth and Automation Authority Governance service pageService 10
Guided Incident and Response Workflows
Guide teams through structured response without depending on anyone remembering every step during a crisis.
- 01 InvestigateThe evidence is reviewed and affected users and systems identified.
- 02 EvaluateContainment options are compared for consequence and reversibility.
- 03 Confirm authorityRequired authority is established and approval requested.
- 04 ExecuteThe selected action is executed or recommended in the organization's own systems.
- 05 VerifyThe result is verified and rolled back if necessary.
- 06 RecordThe final outcome and evidence are preserved for reporting and review.
Ordered response sequenceRequired authority at each stepRollback requirementVerified resultPreserved evidence and final outcomeBoundary. Every consequential action requires human authorization, and action is possible only where the existing platform exposes a supported API.
Open the Guided Incident and Response Workflows service pageService 11
Board, Funder and Framework Reporting
Turn the accumulated Decision Ledger into clear institutional reporting generated from real decision history.
- 01 AssembleMaterial security events and the decisions made about them are collected from the ledger.
- 02 ReconcileActions completed and risks reduced are matched to their verified outcomes.
- 03 QuantifyExternal exposures corrected and privileged access reviewed are counted with evidence attached.
- 04 AssessResponse performance, outstanding gaps and security capacity improvements are stated.
- 05 AttestAccountable owners confirm scope, exceptions and management response before publication.
- 06 PublishThe report and its evidence appendix are versioned and preserved.
Board and funder reportEvidence supporting applicable frameworksSecurity capacity improvementsResidual risk and outstanding gapsDecisions the board itself must takeBoundary. Reports are generated from the organization's actual decision history. KRYOS does not assert compliance and does not reconstruct evidence that was never recorded.
Open the Board, Funder and Framework Reporting service page
Every capability in this platform is provided at no cost to eligible nonprofits, NGOs, think tanks, and nonprofit research institutes under a grant funded by James Scott and administered by the Embassy Row Project.