Where G8TED fits: the action execution layer in the AI security stack
How G8TED composes with NIST AI RMF, CSA MAESTRO, MITRE ATLAS, OWASP Top 10 for LLM, and lifecycle security frameworks.
Where G8TED fits: the action execution layer in the AI security stack
When people compare “AI security frameworks,” they often mix layers that solve different problems.
Here is the clean model:
- NIST AI RMF helps govern AI risk at the enterprise level.
- CSA MAESTRO helps threat model agentic and multi-agent systems.
- MITRE ATLAS helps understand adversary tactics and techniques against AI.
- OWASP Top 10 for LLM Applications helps engineers avoid common LLM app vulnerabilities.
- SAIL helps teams think about AI security across the lifecycle.
- G8TED governs state-changing SOC actions at runtime with outcomes, Risk Reasons, and audit-grade Proof.
If your question is: “Can my agent disable an account, quarantine email, or isolate a host safely, and can I defend that decision later?” That is the G8TED layer.
Related:
- Canonical explainer: /blog/g8ted-safe-soc-autonomy
- What G8TED is (and isn’t): /blog/what-is-g8ted
- G8TED Spec v1.0: /spec/v1.0
The problem: security teams need runtime action governance
In the SOC, automation becomes dangerous when it can:
- change access
- isolate systems
- delete data
- revoke keys
- disrupt investigations or production uptime
Most teams have detections and playbooks. What they lack is a portable, auditable standard for:
- what action is being proposed (typed action vocabulary)
- when it is risky in context (Risk Reasons)
- what the policy outcome is (allow, require_approval, deny, shadow_only)
- what Proof must be recorded so the decision is defensible later
That is the gap G8TED fills.
The “stop comparing apples to oranges” table
Use this table to pick the right tool for the right layer, then compose them.
| Layer | What it governs | Example frameworks | Primary output artifact | How it composes with G8TED |
|---|---|---|---|---|
| Enterprise AI risk governance | Org accountability, risk mgmt process, trustworthy AI | NIST AI RMF | Policies, controls, governance process | Use it to define enterprise expectations; use G8TED to enforce action-level decisions in the SOC |
| Agentic AI threat modeling | Threat modeling for agentic or multi-agent systems | CSA MAESTRO | Threat model, risks, mitigations by layer | Use MAESTRO to find threats; use G8TED to gate and log SOC actions at runtime |
| Adversary technique knowledge base | How attackers target AI systems | MITRE ATLAS | Tactics, techniques, case studies | Use ATLAS for testing and scenarios; encode guardrails and outcomes in G8TED |
| LLM application vulnerability awareness | Common security issues in LLM apps | OWASP Top 10 for LLM Apps | Risk list and mitigations | Use OWASP to harden the app; use G8TED to govern high-impact actions the app proposes |
| Lifecycle AI security blueprint | Security across build to runtime to retirement | SAIL and similar | Lifecycle risks and mitigations | Use SAIL to organize the program; use G8TED for the SOC execution layer |
What “good” looks like in practice
A strong stack uses multiple layers at once:
- Engineering uses OWASP guidance to reduce prompt injection, insecure output handling, and agency risks.
- Security teams use ATLAS techniques for testing how an attacker would bypass controls.
- Architects threat model agentic systems with MAESTRO to identify cross-layer risks.
- Leadership uses NIST AI RMF and lifecycle frameworks to set governance expectations.
- The SOC uses G8TED to make runtime decisions for state-changing actions: allow, require_approval, deny, shadow_only.
A concrete composition workflow
Here is a practical sequence you can run this month:
Step 1: Threat model the agent and tool chain (MAESTRO)
Identify where an attacker can influence:
- inputs (tickets, alerts, webhook payloads, prompts)
- tool calls (overbroad scopes, weak authorization)
- memory and retrieval (poisoning)
- outputs (unsafe execution paths)
Step 2: Red-team and scenario test (ATLAS)
Pick 10 adversary techniques relevant to your environment and test:
- can an attacker trigger a destructive action?
- can they manipulate the agent’s scope?
- can they cause false attribution?
Step 3: Harden the LLM app and integrations (OWASP)
Reduce the most common failure modes:
- prompt injection paths
- insecure output handling
- excessive agency and unsafe tool permissions
Step 4: Enforce runtime action governance (G8TED)
Define typed actions you care about and set:
- default outcomes by action type and risk tier
- Risk Reason overrides (blast radius, Tier0/VIP, incomplete evidence, input tampering)
- minimum Proof fields per outcome
Step 5: Align with enterprise governance (NIST AI RMF)
Map the operational controls back to enterprise expectations:
- accountability and approvals
- monitoring and measurement
- incident response and review
- continuous improvement
The key claim
These frameworks are not substitutes. They are layers.
G8TED is the standard for action execution governance in the SOC: typed actions, outcomes, Risk Reasons, and audit-grade Proof.
Everything else can be upstream input to that decision layer.
FAQ
Is G8TED “an AI governance framework”?
Not in the enterprise sense. G8TED is action governance for SOC execution.
Is MAESTRO a competitor to G8TED?
No. MAESTRO is threat modeling for agentic systems. G8TED is runtime policy and Proof for state-changing SOC actions.
Do I need ATLAS and OWASP if I use G8TED?
Yes, if you are building or deploying agentic AI. They help you reduce risk in the system. G8TED governs what the SOC is allowed to execute.
References
- NIST AI Risk Management Framework (AI RMF 1.0): https://www.nist.gov/itl/ai-risk-management-framework
- CSA MAESTRO (Agentic AI Threat Modeling Framework): https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro
- MITRE ATLAS: https://atlas.mitre.org/
- OWASP Top 10 for LLM Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/
- SAIL Framework (Pillar Security): https://www.pillar.security/sail
Changelog
- 2025-12-18: Initial post published.