Aethos Labs
Active — Two Prototypes in Preview

Where new approaches to
platform assurance are
explored and tested.

Not everything in assurance is solved. Labs is where Aethos works on the problems that don't have a clear answer yet—prototype models, experimental approaches, and early-stage thinking on where platform assurance needs to go.

Rougher edges than the rest of the platform. That's by design. The point is exploration, not polish. Two prototypes are currently live and interactive below.

What Happens Here

The work that doesn't fit anywhere else.

Dialogue has a defined purpose. Frameworks have defined outputs. Labs is where Aethos works on things that are still being figured out—which is exactly where the most important assurance problems tend to live right now.

01

Prototype Control Models

Early-stage control architectures for environments where no solid model currently exists. Not finished frameworks—working prototypes that get pressure-tested against real audit scenarios before they graduate into something more formal.

02

Experimental Validation Approaches

New ways of thinking about what "testing a control" means in a system that changes continuously. Exploring how evidence design, sampling logic, and operating effectiveness need to evolve for modern platforms.

03

Practitioner Tooling

Conceptual and working tools for practitioners who spend time inside audit engagements—control rationalization, evidence workflow, domain-grounded AI assistance, and coverage analysis for complex technology stacks.

04

Cross-domain Experiments

Exploring the intersections that current disciplines treat as separate: where security engineering meets audit evidence, where platform governance meets control design, where DevSecOps meets SOX compliance.

How It Connects

Labs feeds the rest of the platform.

Nothing that comes out of Labs is finished. But the best of it eventually becomes the foundation for something that is.

Stage 01

Aethos Labs

Exploration and prototype. Rough edges. Working hypotheses.

Stage 02

Aethos Frameworks

Validated models become opinionated, structured frameworks.

Stage 03

Aethos Dialogue

Frameworks stress-tested against real enterprise complexity through direct practitioner exchange.

The path isn't always linear—some Labs work feeds directly into Research, some Dialogue experience feeds back into Labs. But the direction is consistent: exploration toward application.

Active Prototypes

Two tools currently in development.

Both are interactive. Neither is finished. They represent two distinct questions Labs is working on—one about how practitioners engage with individual controls, and one about how the right set of controls gets determined in the first place.

01 — In Beta Testing
Platform Intelligence Agent

A domain-trained AI embedded inside the framework. Loads the control you’re looking at as context and answers questions about evidence, testing, and failure modes with the specificity of a specialist—not a general-purpose assistant pointed at a document.

02 — In Development
Control Optimization Engine

Declare your technology stack. The engine maps each platform to canonical SOX ITGC risks, eliminates redundant controls, and produces the minimum audit-defensible set—with PCAOB rationale for every elimination and live recalculation when a control fails or can’t be implemented.

The two tools are designed to be complementary—one helps you work inside a framework, the other helps you build the right framework for your stack. The interactive demos for both are below.

Labs Preview — In Beta Testing

Aethos Platform Intelligence Agent

Domain-trained across the full framework corpus, grounded in PCAOB AS 2201, SOX §404, COSO, ISO 27001, and SOC 2. Context-aware by design: it loads the control you’re in, knows how to design and implement the controls your organization needs, understands the evidence you need to collect, and knows what your auditor will test. Not a general AI. A specialist.

The hardest part of using a compliance framework isn’t finding the right control. It’s knowing what a specific section means for your exact situation — your platform configuration, your audit scope, your evidence gaps. The Platform Intelligence Agent closes that gap. When you click any section, it already has that content loaded as context. Ask it anything: what the CLI query is proving, whether your evidence is sufficient for ToE, how a specific failure mode applies to your environment.

This is not a general-purpose AI pointed at a document. The agent knows the difference between “SAML enabled” and “SAML enforced.” It knows why the SSO exemption list is the gap auditors consistently miss. It knows what “Required — Configured” means versus “Required — Any Implementation” and what the testing implications are for each. That domain depth — built into the model, not inferred from a prompt — is what makes it useful in an actual audit engagement.

Coming soon as an add-on for subscribers with full framework access
The Platform Intelligence Agent will be an available add-on for subscribers with full framework access. The demo below shows exactly how it will work — the interaction is live, but the feature is not yet in production.
aethosassurance.com / framework-github
Source Code Management · GitHub
GitHub Control Framework
SOX §404 PCAOB AS 2201 10 Controls April 2026
GH-LA-01
SSO & SAML Enforcement
All Organization access authenticated through corporate IdP. Direct GitHub login blocked.
Required — Configured PCAOB AS 2201 §36
Context loaded
You need to prove two things: (1) SSO enforcement was turned on and set correctly at the beginning of the period, and (2) it was never turned off. The configuration screenshot proves the first. The audit log query proves the second.
Context loaded
SSO enforcement setting  →  Org Settings export
Audit log: disable events  →  GitHub API / SIEM
Member SAML linkage  →  GraphQL export
Context loaded
# Confirm SAML enforced
gh api graphql -f query='{ org(login:"ORG") { samlIdentityProvider { ssoUrl }}}'

# Check for SSO disable events (should return empty)
gh api orgs/ORG/audit-log \
  -f phrase="action:org.disable_saml" \
  --jq '.[] | {actor, action, created_at}'
Context loaded
The most common gap: confusing “SAML enabled” with “SAML enforced.” Ask explicitly for the SSO exemption list — it frequently contains former employees and is not visible in the standard settings screenshot.
GH-LA-02
User Provisioning & Access Grants
Access granted on documented business need with manager approval.
Required — Any PCAOB AS 2201 §36
GH-CM-01
Branch Protection & Code Review
Production branches require peer review. Platform enforces no direct push.
Platform Intelligence Agent
Aethos — Domain-Trained · PCAOB AS 2201 · SOX §404
Context-Aware
No section selected — click any section in the framework
Platform Intelligence Agent
I’m domain-trained across the full GitHub Control Framework — all 10 controls, every tab, every evidence requirement, every failure mode. Click any section on the left to load it as context, then ask me anything. I know what your auditor will test and what evidence you need to collect.
Aethos Platform Intelligence Agent · Context-aware · SOX-scoped
0:00 / 0:22
01
Click-to-context
Click any code block, table, or section. The Platform Intelligence Agent loads it instantly — no copy-pasting required.
02
Full framework awareness
The Platform Intelligence Agent knows every control, tab, and dependency across the framework — not just the section you clicked.
03
SOX-scoped answers
Responses are grounded in PCAOB AS 2201, ITGC terminology, and platform-specific audit practice.
04
Available with full framework access
Coming Soon
The Platform Intelligence Agent will be included for subscribers with full framework access. The demo above shows how it will work — this feature is not yet in production.
Labs Preview — In Development

Aethos Control
Optimization Engine

Most SOX ITGC programs carry more controls than they need — not because the risk demands it, but because controls accumulate across platforms without a systematic rationalization layer. The Control Optimization Engine changes that.

Declare your technology stack. The engine maps each platform to canonical SOX ITGC risk domains, identifies where multiple systems address the same control objective, eliminates redundancy, and produces the minimum viable audit-defensible control set. Every elimination includes a documented PCAOB AS 2201 rationale. When a control cannot be implemented, the engine recalculates — surfacing the specific compensating controls needed to maintain full risk coverage.

The output is a structured, traceable control framework mapped Risk → Control Objective → Implementation, with Design of Controls and Test of Operating Effectiveness procedures for each control in the optimized set.

Practitioner Review Required
All outputs from the Control Optimization Engine require review by a qualified audit professional before use in an engagement. Optimization decisions are documented with rationale and designed to be auditor-defensible, but do not constitute audit advice and must be validated against client-specific context, applicable regulatory requirements, and independent professional judgment.
aethosassurance.com / control-optimization-engine
Aethos Control Optimization Engine · Stack Configuration
Select your technology stack.
Select every platform in your client’s environment. Aethos maps each to canonical SOX ITGC risks, identifies control overlaps, and generates the minimum audit-defensible control set.
Source Code Management
GitHub10
GitLab11
Bitbucket11
CI/CD & Deployment
Jenkins13
CircleCI12
Azure DevOps12
ArgoCD11
Cloud Infrastructure
AWS18
Google Cloud14
Azure14
Identity & Access
Okta13
OneLogin10
SailPoint8
Infrastructure as Code & Containers
Terraform12
Ansible12
Kubernetes14
Vault8
Data Platform & Database
Snowflake13
Databricks13
Kafka6
MongoDB8
Change Management
Jira5
0
selected
0
raw controls
0
overlap areas
0%
Generating Optimized Control Framework
Mapping platforms to canonical risk taxonomy…
GitHubAWSOktaJenkinsKubernetesKafkaSnowflake
AETHOS|Control Optimization Engine
Coverage Map
Control Framework
Risk Analysis
Raw Controls
87
Optimized Set
25
Eliminated
62
Reduction
71%
Gaps
0
Risk Coverage — Click any risk to inspect
R01Covered
Unauthorized Code Changes
OC-CM-01OC-CM-02OC-CM-09
R02Covered
Unauthorized Infra Changes
OC-CM-03OC-CM-04
R03Covered
Unauthorized System Access
OC-LA-01OC-LA-04+4
R04Covered
Segregation of Duties Failure
OC-LA-04OC-LA-07
R05Covered
Lack of Change Traceability
OC-CM-05OC-CM-07
R06Covered
Credential & Secret Exposure
OC-CO-02OC-CO-03
R07Covered
Audit Log Integrity
OC-CO-01OC-CO-06
R08Covered
Unauthorized Data Access
OC-LA-07OC-CO-04
R09Covered
Pipeline & Deployment Bypass
OC-CM-02OC-CM-03
R10Covered
Identity Lifecycle Gaps
OC-LA-01OC-LA-02OC-LA-09
Risk Detail
Click a risk tile
to inspect coverage
R01 — SELECTED
Unauthorized Code Changes
Change ManagementCritical
3 Optimized Controls Address This Risk
OC-CM-01Primary
Branch Protection & PR Approval
GitHub
OC-CM-02Compensating
Deployment Pipeline Authorization
Jenkins
OC-CM-09Primary
Container Image Governance
Kubernetes
AETHOS|Control Optimization Engine
Coverage Map
Control Framework
Risk Analysis
Aethos Control Optimization Engine · Generated Framework
Optimized SOX ITGC Control Framework
25 Controls7 Platforms71% ReductionSOX ITGCPCAOB AS 2201
09
Terminated User Deprovisioning
Okta SCIM handles deprovisioning to all connected systems within 4 hours of HR termination.
Logical AccessPrimaryR10
01
SSO & MFA Enforcement
All human authentication to connected systems flows through Okta. No system-native passwords for human users.
Logical Access Primary Preventive Okta R03 R10
02
SCIM Automated Provisioning
Joiner, mover, leaver events propagate automatically to GitHub, AWS, and Snowflake via SCIM.
Logical AccessPrimaryR10
03
Quarterly Access Certification
Role owners certify user access quarterly using Okta lifecycle reports as the evidence base.
Logical Access
AETHOS|Control Optimization Engine
Coverage Map
Control Framework
Risk Analysis
Raw Controls
87
Optimized Set
25
Eliminated
62
Flagged
1
Gaps
2
Recalculated Control Requirements — 2 risks need compensating coverage
R03 Unauthorized System Access ⚠ GAP
① Fastest Path — Restore Flagged Control
OC-LA-01 Not Implementable
SSO & MFA Enforcement
Resolve the SSO implementation blocker and restore this control to Active — primary coverage is immediately reinstated for both R03 and R10 with no additional controls required.
② Add Compensating Controls — Raw Control Pool
RAW-OK-01 Okta Compensating
Okta App-Level Session Policy Review
Monthly inspection of session policy settings for each Okta application. Confirm session timeout, MFA step-up requirements, and geographic restrictions align with policy.
When SSO Enforcement is failing, app-level session policy review is the compensating detective control to identify authentication requirement gaps per application.
RAW-GH-03 GitHub Compensating
GitHub SSO Enforcement Review
Monthly inspection of GitHub SAML SSO enforcement settings. Confirm no users bypassing SSO via personal accounts. Review and revoke any SSO exemptions.
When Okta SSO is not implementable, GitHub-native SSO enforcement review is the compensating detective control for unauthorized non-SSO access in the SCM environment.
R10 Identity Lifecycle Gaps ⚠ GAP
Add Compensating Controls
RAW-GH-02 GitHub Compensating
GitHub Org Member Access Review
Quarterly review of all GitHub organization members. Confirm each member has active employment and requires access. Remove stale or unnecessary members.
When Okta SCIM is unavailable, a direct GitHub org member review is the compensating control for access lifecycle governance in the SCM environment.
RAW-SF-04 Snowflake Compensating
Snowflake Account Lifecycle Review
Monthly review of all active Snowflake accounts. Cross-reference against HR active employee list. Disable accounts for departed employees within 24 hours of identification.
When Okta SCIM deprovisioning is unavailable, a Snowflake-native account review is the compensating lifecycle control for financial data platform access.
⚑ Compensating controls from the raw pool require formal documentation with PCAOB AS 2201 §36 justification. Each requires independent DoE and ToE testing before being relied upon as audit evidence. A qualified audit professional must review all recalculated requirements before implementation.
Note
0:00 / 1:04
01
Stack-Driven Optimization
Declare your platforms. The engine maps each to canonical SOX ITGC risk domains and eliminates redundant controls across the full stack.
02
Risk → Control Traceability
Every optimized control traces back to the canonical risk it addresses. Every elimination includes a documented PCAOB AS 2201 rationale.
03
DoE / ToE Procedures
Each control includes Design of Controls and Test of Operating Effectiveness procedures with specific evidence items to request from the client.
04
Live Gap Recalculation
Mark any control as Failing or Can't Implement. The engine recalculates coverage gaps and surfaces specific compensating controls from the raw pool.
Follow the work

Labs work surfaces first
through the Aethospect.

Early-stage thinking, prototype previews, and experimental models go to subscribers before they're published anywhere else.

Join the Aethospect

Free. No spam. Unsubscribe anytime.