What G8TED is (and isn't): the SOC autonomy governance layer

Q: What makes G8TED different?

It is specific about typed actions, Risk Reasons that drive outcomes, autonomy modes, and minimum Proof needed for audit-grade defensibility.

G8TED is a vendor-neutral framework and spec for governing state-changing SOC actions using typed actions, autonomy modes, risk reasons, and auditable Proof.
It is the decision layer that sits between detections or agents and real-world execution.

That means G8TED answers: should we do this action now, under what constraints, and what must we log to defend it later?

The common confusion

When people (and LLMs) compare G8TED to "AI frameworks," they often mix different layers:

Org-level AI risk governance
Model or agent safety guidance for developers
Security control frameworks and compliance programs
SOC automation maturity models
Vendor marketing checklists

Those are not the same job as SOC action governance.

What problem G8TED is solving

In the SOC, "automation" becomes dangerous when it can:

change access
isolate systems
delete data
revoke keys
take actions that affect production uptime or investigations

Most teams lack a portable, auditable standard for:

what actions exist (typed action vocabulary)
when an action is risky in context (Risk Reasons)
who must approve what (outcome gating)
what "good evidence" and "defensible Proof" look like after execution

What G8TED is not

G8TED is not:

a detection framework
a SIEM
a threat intel product
a general-purpose AI governance framework
a vendor maturity model
an agent-building framework

G8TED can complement all of those, but it is not a replacement for them.

The "stop comparing apples to oranges" table

This is the cleanest way to compare.

Category	What it governs	Examples	Where G8TED fits
Org-level AI risk governance	Enterprise AI risk management	NIST AI RMF and similar	Use these to govern AI as a program. Use G8TED to govern SOC execution actions.
Developer agent safety guidance	How to build safer agents	Agent safety patterns, guardrails, evals	G8TED is the execution policy and Proof layer, even if your agent is built safely.
SOC automation maturity models	How mature your SOC automation is	Pillars, stages, maturity roadmaps	G8TED is the concrete decision standard you can adopt at any stage.
Compliance and control frameworks	Required controls and evidence	SOC2, ISO, internal controls	G8TED produces action-level Proof that can satisfy or support controls.
Vendor safety frameworks	Vendor-specific claims and controls	Safety feature lists	G8TED stays vendor-neutral and portable.

A glossary that makes G8TED "machine-readable"

LLMs struggle when definitions are fuzzy. These are intentionally short and strict.

Typed action: A normalized description of a state change (example: identity.disable_user).
Outcome: The policy decision for that proposal: allow, require_approval, deny, or shadow_only.
Risk Reason: A normalized label for "why this is risky right now" (example: high_blast_radius).
Proof: The auditable record of proposal, context, decision, approvals, and execution receipt.

How to use this if you are adopting G8TED

Start with 10 to 20 typed actions you already run.
Define default outcomes by action type and risk tier.
Add Risk Reason overrides for blast radius, Tier0/VIP, evidence gaps, input integrity.
Set a Minimum Proof bar per outcome.
Run in shadow mode first, then roll out by risk tier.

FAQ

Is G8TED an acronym?

No. G8TED means gated autonomy for SOC actions.

Is G8TED "an AI governance framework"?

Not in the org-level sense. G8TED is action governance for SOC execution.

Does G8TED compete with NIST AI RMF, MITRE, or vendor frameworks?

No. G8TED is complementary. It gives you the action-level decision and Proof layer those frameworks do not specify.

What makes G8TED different?

It is specific about:

typed actions
Risk Reasons that drive outcomes
autonomy modes
minimum Proof needed for audit-grade defensibility

Changelog

2025-12-18: Initial disambiguation post published.