Safe SOC Autonomy
G8TED: Safe SOC Autonomy Framework
Most SOCs already automate. What they rarely agree on is when it is actually safe to let automation run on its own. G8TED is a vendor neutral framework for Safe SOC Autonomy. It defines typed security actions, autonomy modes, risk tiers, guardrails, and evidence requirements so teams can move faster without losing control.
What G8TED defines
A consistent language for governing AI driven security automation. G8TED takes the instincts your best analysts already have and turns them into something you can write down, share, and enforce.
Domains and typed actions
Identity.disable_user, endpoint.isolate_host, cloud.revoke_keys, email.quarantine. Each action is explicitly typed, with preconditions, mappings into your stack, and what good evidence looks like when it runs.
Autonomy modes
Shadow, Assist, Autopilot, Deny. These are the four answers to a simple question: can this run on its own, or does a human stay in the loop. You set them per action and per risk tier, not as a vague global policy.
Risk tiers
Normal users and Tier0 or VIP personas are not the same problem. G8TED bakes that in. Different tiers drive stricter evidence and review requirements for sensitive accounts and assets.
Guardrails and evidence
Every autonomy decision should be explainable after the fact. Guardrails define the preconditions and blast radius checks. Evidence rules define what gets logged so you can prove to yourself, your board, and your auditors why an action was allowed.
How G8TED is enforced
G8TED is a specification. To use it in practice, you plug it into an enforcement layer that can evaluate autonomy modes, guardrails, and evidence rules for every action.
- An internal control plane your team already runs for SOC automation.
- A commercial autonomy firewall that sits in front of agents and tools.
- Neodyne Gateway, which is one reference implementation that loads the G8TED spec, evaluates requests, and records proofs for every automated action.
G8TED defines the rules. Your enforcement layer decides how and where those rules run.
How to adopt G8TED
- Map your current runbooks and automations to G8TED typed actions per domain. Start simple: Identity and Endpoint alone are usually enough to find gaps.
- Pick Conservative, Balanced, or Aggressive postures that match your real risk appetite, not just your slideware.
- Start in Shadow mode so every action is observable but not yet enforced. Move the clean, low regret actions to Assist and then to Autopilot.
- Instrument guardrails and evidence capture before you widen blast radius. If you cannot explain an automated decision in a post incident review, it is not ready for Autopilot.
FAQ
Common questions about how to use the framework and where it fits in your SOC stack.
What is the G8TED framework?
G8TED is a vendor neutral Safe SOC Autonomy Framework. It defines typed security actions, autonomy modes, risk tiers, guardrails, and evidence requirements so teams can safely automate SOC workflows and still explain every decision.
How is G8TED different from NIST CSF or MITRE ATT&CK?
NIST CSF and MITRE ATT&CK describe controls and attacker techniques. G8TED sits beside them and answers a different question: when is it safe to let an automated system actually take an action like disabling a user, quarantining a host, or revoking OAuth tokens.
How does G8TED relate to Neodyne Gateway?
G8TED is the framework and catalog. Neodyne Gateway is a reference enforcement layer that implements it in practice. It loads the G8TED spec, evaluates policies and guardrails in real time, and records the proofs and evidence for every automated action. Other internal platforms and vendors can implement G8TED as well.
Who should use G8TED?
CISOs, SOC leaders, security architects, and product teams who need a consistent way to govern AI driven automation across identity, endpoint, cloud, email, and other security domains. It is also useful for vendors who want a common language for what their agent is allowed to do.
Can I use G8TED without Neodyne Gateway?
Yes. The framework is published independently so internal platforms and other vendors can adopt the typed actions and autonomy model, even if they do not deploy Neodyne Gateway. Gateway is a reference implementation, not a requirement.