The AWS Customer Incident Response Team works with customers to help them recover from active security incidents. As part of this work, the team often uncovers new or trending tactics used by various threat actors that take advantage of specific customer configurations and designs.

Understanding these tactics can help inform your architecture decisions, improve your response plans, and detect these situations if they occur in your environment.

This post examines a new approach we’re seeing threat actors use after they gain control of a customer account, which is to remove it from the customer’s AWS Organizations implementation and the policies and protections that structure provides.

The described tactic doesn’t take advantage of vulnerabilities within AWS services, instead it uses an unexpected opportunity created by a specific configuration or design to make unauthorized use of resources within an AWS account.

This approach starts with the threat actor using credentials that have the organizations:LeaveOrganizationpermission grant. This permission provides access to the LeaveOrganizations API call, which, when called from a member account, attempts to remove that account from the organization.

It’s important to remember that while this approach might use a compromised root credential, threat actors can also use other methods to elevate their access until they have the required permission or the ability to assume a role that has this permission, or they have the ability to grant their current credential this permission. This is why a least privilege approach to authorization is critical to protect your environment. To learn more, see AWS Identity and Access Management (IAM) documentation and the AWS Organizations guidance on organizational unit (OU) design and service control policy (SCP) implementation.

After the account is removed from the organization, the restrictions inherited as a part of that organization—such as SCPs that were preventing destructive actions, limiting which AWS Regions could be used, or blocking specific API calls—no longer apply. The account is also no longer part of consolidated billing, so the organization’s billing alerts and cost anomaly detection will no longer cover activity in that account. AWS CloudTrail organization trails stop capturing events from the departed account, and Amazon GuardDuty findings managed through a delegated administrator will stop flowing to the central security account.

The result is frequently that the organization loses visibility into the account while it still contains resources for the organization. Related threat technique catalog entries:

• T1078.A002: Account Root User: Initial access using compromised root credentials
• T1078.004: Cloud Accounts: Initial access using compromised IAM credentials
• T1098: Account Manipulation: Privilege escalation and modifying account settings to maintain control
• T1666.A002: Leave AWS Organization: Removing a member account from the organization to bypass SCPs and governance controls
• T1562.008: Disable Cloud Logs: Loss of centralized logging visibility after leaving the organization

When an account attempts to leave an organization, at least two API calls are logged in CloudTrail: organizations:AcceptHandshake and organizations:LeaveOrganization. If you have centralized logging configured, these might be among the last events you see from the compromised account. After it leaves the organization, it might default to logging events within the account to its own CloudTrail logs. The following CloudTrail events are associated with accounts joining or leaving an organization. These should be investigated unless they’re part of an approved operational workflow that’s used by your teams to manage AWS Organizations.

Implement an SCP that denies the organizations:LeaveOrganization action. AWS Organizations provides detailed guidance on implementing this control, including the specific SCP policy JSON and advice on how to design your OU structure to accommodate legitimate account migrations while keeping the protection in place for production and development accounts.

SCPs act as guardrails that limit what any IAM policy can permit within member accounts. We strongly encourage every customer using AWS Organizations to verify whether this SCP is in place today and take steps to implement it if it is not. This SCP is quick to deploy and has minimal operational impact, providing a process to carefully manage and consider separating a member account from an organization.

Because this action can originate from any compromised IAM principal with the organizations:LeaveOrganization—not just root—the principle of least privilege for IAM permissions is an important complementary control. Limiting which users and roles can add, remove, or change policies, assume other roles, or modify their own permissions reduces the paths available for unauthorized permission changes. Regularly reviewing IAM policies for overly broad permissions—particularly iam:AttachRolePolicy, iam:AttachUserPolicy, iam:PutRolePolicy, and sts:AssumeRole with wide trust policies—will help reduce the scope of what a compromised principal can do.

Root account security remains important, because root compromise is a common entry point for this pattern. Enabling multi-factor authentication (MFA) on every root user, deleting any root access keys, and adopting centralized root access management to remove root credentials from member accounts entirely, will help reduce the risk.

This technique highlights a broader theme that we see across engagements: threat actors are increasingly aware of how AWS governance controls work, and they’re taking deliberate steps to separate accounts from the controls that an organization provides. Disabling AWS CloudTrail, deleting Amazon GuardDuty detectors, and removing accounts from organizations are all variations of the same strategy: removing your accounts from the guardrails and visibility that would otherwise constrain their activity and help the customer respond.

The controls to prevent this are available today and straightforward to implement. We encourage teams to start with the AWS Organizations service team’s guidance and implement the DenyLeaveOrganizationSCP—it’s the single highest-impact, lowest-effort control for this technique. Beyond that, reviewing SCP coverage across your OU structure, verifying that both root credentials and IAM permissions are properly secured across all member accounts, and ensuring that your detection and response processes account for this technique will contribute to a stronger posture. The Threat Technique Catalog for AWS includes detection guidance for the underlying techniques.

• Threat Technique Catalog for AWS – Matrix
• T1078.A002: Account Root User
• T1078.004: Cloud Accounts
• T1098: Account Manipulation
• T1666.A002: Leave AWS Organization
• Essential security controls to prevent unauthorized account removal in AWS Organizations
• Centrally manage root access for member accounts
• AWS Organizations Service Control Policies
• Amazon GuardDuty
• AWS CloudTrail User Guide

If you have feedback about this post, submit comments in the Comments section below.

Organizations often struggle to enforce security and compliance requirements consistently across their cloud infrastructure. In one environment, a workload might be deployed in an AWS Region that was never approved for that class of data. In another, a security group might allow broader access than intended. Required tags might be missing. Encryption might be assumed but not configured. These gaps create risk, increase review effort, and make audits harder than they need to be.

Many organizations already have standards that describe what good infrastructure looks like. The more difficult problem is making sure those expectations are checked the same way across repositories, environments, and teams before infrastructure is deployed. Manual review helps, but it doesn’t scale when delivery moves faster and more teams provision infrastructure directly.

Policy as code helps address this problem. It turns control intent into preventive checks that run in delivery workflow.

A pattern-based policy model makes those checks more straightforward to review, maintain, and explain. Teams can organize policy checks around recurring control patterns such as required metadata, allowed configuration, exposure restriction, protection enforcement, and privilege constraint, as shown in Figure 1. This structure simplifies policy coverage across security, governance, risk, and compliance (GRC), and engineering teams.

This post shows you how to use Open Policy Agent (OPA) in continuous integration and continuous delivery (CI/CD) pipelines to validate Amazon Web Services (AWS) infrastructure changes before deployment. You will learn how to structure policy checks around recurring control patterns, fit those checks into a gated delivery workflow, and retain validation artifacts that support both release decisions and later audit review.

The Compliance Engineering and Automation team from AWS Security Assurance Services (AWS SAS) frequently helps customers implement policy as code as part of broader control design and compliance automation efforts. This post focuses on the pre-deployment layer. Runtime monitoring and post-deployment controls still matter, but they are outside the scope of this article.

Figure 1: Pattern-based policy as code in a gated delivery workflow

Teams sometimes build rules one service at a time, which can make policy as code libraries difficult to review and extend as the library grows. Similar control requirements can be expressed differently across repositories, and teams lose a common way to discuss what the policies are enforcing.

A pattern-based approach organizes policies around recurring control intent rather than service-specific checks, as shown in Figure 2. This makes coverage more straightforward to review, explain, and evolve as infrastructure changes.

A practical set of patterns includes:

• Required metadata – for tags and other fields used for ownership, support, cost allocation, and automation.
• Allowed configuration – for approved Regions, accepted deployment boundaries, and other approved settings.
• Exposure restriction – for configurations that make infrastructure more reachable than intended, such as public ingress or internet-facing resources in the wrong environment.
• Protection enforcement – for baseline safeguards such as encryption, logging, or deletion protection.
• Privilege constraint – for AWS Identity and Access Management (IAM) definitions and access patterns that need tighter validation.

Figure 2: Recurring control patterns used to organize policy as code checks

This post focuses on the preventive layer. You still need runtime controls, drift monitoring, remediation workflows, and compliance reporting. On AWS, AWS Organizations, AWS Control Tower, AWS Config, and AWS Security Hub remain important after resources exist.

OPA fits earlier in the process and validates that infrastructure changes align with expectations. OPA evaluates structured input (HashiCorp Terraform plan JSON) against policy logic. It doesn’t replace AWS governance services that provide organizational guardrails, continuous monitoring, and resource level enforcement after resources exist.

As shown in Figure 3:

• OPA – Checks proposed changes before deployment
• AWS Organizations and Control Tower – Establish organizational guardrails
• AWS Config and Security Hub – Provide visibility and monitoring after resources exist
• Service-level protections – Enforce settings at the resource boundary

Figure 3: OPA validates changes pre-deployment; AWS services enforce guardrails, monitoring, and controls post-deployment

Use the following steps to integrate OPA policy evaluation into your delivery workflow:

Submit a change through a pull request or merge request.

1. Run early validation checks such as formatting, syntax validation, and dependency checks.
2. Generate a Terraform plan and convert it to JSON format.
3. Evaluate the plan (JSON format) against the shared OPA policy library.
4. Publish the validation report as an artifact.
5. Run additional automated quality checks as needed.
6. Use the validation artifact during approval decisions for higher-risk environments.
7. Deploy approved changes.
8. Continue post-deployment monitoring through AWS-native governance services.

Quality gates provide automated pass or fail results based on defined criteria. Approval gates control whether a change moves into a protected environment. This separation matters—manual approval isn’t the first place where anyone notices missing tags, a disallowed AWS Region, or public ingress. Automated checks identify those issues earlier. OPA belongs in the automated gate layer. Its output also feeds the approval process.

A pattern-based library structure, as shown in the following sample, keeps the policy model closer to how teams talk about controls.

  opa-policies/
  ├── patterns/
  │ ├── baseline/ # Foundational security
  │ ├── tagging/ # Required tags
  │ ├── networking/ # Network controls
  │ ├── logging/ # Logging enablement
  │ ├── encryption/ # Encryption at rest and transit
  │ └── iam/ # IAM best practices
  ├── shared/
  │ ├── helpers.rego
  │ └── messages.rego
  ├── tests/
  ├── fixtures/
  └── docs/

A compliance engineer might describe a requirement as mandatory metadata. A cloud engineer might describe the same requirement as a tagging standard. The pattern structure helps both teams talk about the same thing.

This example demonstrates the protection enforcement pattern for Amazon Simple Storage Service (Amazon S3). The goal is to verify that S3 bucket access is protected in transit by requiring a bucket policy that denies requests when aws:SecureTransport is set to false.

The policy checks two things: whether an S3 bucket policy includes a deny statement that blocks non-encrypted requests, and whether an S3 bucket has any corresponding bucket policy at all. The rule evaluates both create and update actions in the Terraform plan JSON.

This example uses an explicit deny rather than an allow statement for secure transport. An explicit deny overrides allow statements that might exist elsewhere in the policy set, making it the stronger enforcement pattern.

package compliance.amazon_s3.ssl

import future.keywords.in
import future.keywords.contains
import future.keywords.if

# Deny: S3 bucket policy missing SecureTransport deny statement
deny contains msg if {
    resource := input.resource_changes[_]
    resource.type == "aws_s3_bucket_policy"
    is_create_or_update(resource.change.actions)

    policy_value := resource.change.after.policy
    policy := json.unmarshal(policy_value)

    not has_secure_transport_deny(policy)

    msg := sprintf(
        "[S3-OPA-1] Resource '%s' does not enforce SSL/TLS. Bucket policy must include a Deny statement with Condition Bool aws:SecureTransport set to \"false\".",
        [resource.address]
    )
}

# Deny: S3 bucket created without any corresponding bucket policy
deny contains msg if {
    resource := input.resource_changes[_]
    resource.type == "aws_s3_bucket"
    is_create_or_update(resource.change.actions)

    bucket_name := resource.change.after.bucket
    not has_bucket_policy(bucket_name)

    msg := sprintf(
        "[S3-OPA-1] Resource '%s' (bucket '%s') has no bucket policy. A bucket policy with a Deny statement for aws:SecureTransport \"false\" is required.",
        [resource.address, bucket_name]
    )
}

is_create_or_update(actions) if { actions[_] == "create" }
is_create_or_update(actions) if { actions[_] == "update" }

has_bucket_policy(bucket_name) if {
    bp := input.resource_changes[_]
    bp.type == "aws_s3_bucket_policy"
    is_create_or_update(bp.change.actions)
    bp.change.after.bucket == bucket_name
}

has_secure_transport_deny(policy) if {
    stmt := policy.Statement[_]
    stmt.Effect == "Deny"
    stmt.Condition.Bool["aws:SecureTransport"] == "false"
    stmt.Principal == "*"
    action := stmt.Action
    action == "s3:*"
}

When you adapt this example, decide whether you want to require one exact policy shape or support several equivalent forms of enforcement. A strict rule is more straightforward to reason about, but it might create false positives if teams already use alternate policy structures that achieve the same outcome.

This example implements the exposure restriction pattern. The goal is to identify Amazon Virtual Private Cloud (Amazon VPC) security group configurations that allow public ingress on sensitive ports before those rules are deployed.

The policy evaluates both inline aws_security_group ingress rules and standalone aws_security_group_rule resources, because customer repositories often use both modeling styles.

This example checks directly for public ingress on sensitive ports rather than trying to infer whether later controls might reduce actual exposure. Security group rules are a direct expression of intended network reachability, making them the right place to enforce this pattern early.

package compliance.amazon_vpc.ingress

import future.keywords.in
import future.keywords.contains
import future.keywords.if

# Sensitive ports that must not be open to the internet
sensitive_ports := {22, 3389, 5432}

# Deny: aws_security_group with inline ingress open to 0.0.0.0/0 on sensitive ports
deny contains msg if {
    resource := input.resource_changes[_]
    resource.type == "aws_security_group"
    is_create_or_update(resource.change.actions)

    ingress := resource.change.after.ingress[_]
    ingress.cidr_blocks[_] == "0.0.0.0/0"

    port := sensitive_ports[_]
    ingress.from_port <= port
    ingress.to_port >= port

    msg := sprintf(
        "[VPC-OPA-1] Resource '%s' allows ingress from 0.0.0.0/0 on port %d. Restrict access to specific CIDR ranges.",
        [resource.address, port]
    )
}

# Deny: aws_security_group_rule with type "ingress" open to 0.0.0.0/0 on sensitive ports
deny contains msg if {
    resource := input.resource_changes[_]
    resource.type == "aws_security_group_rule"
    is_create_or_update(resource.change.actions)

    resource.change.after.type == "ingress"
    resource.change.after.cidr_blocks[_] == "0.0.0.0/0"

    port := sensitive_ports[_]
    resource.change.after.from_port <= port
    resource.change.after.to_port >= port

    msg := sprintf(
        "[VPC-OPA-1] Resource '%s' allows ingress from 0.0.0.0/0 on port %d. Restrict access to specific CIDR ranges.",
        [resource.address, port]
    )
}

is_create_or_update(actions) if { actions[_] == "create" }
is_create_or_update(actions) if { actions[_] == "update" }

When you adapt this example, review which ports to treat as sensitive, whether both IPv4 and IPv6 exposure need checking, and how to handle approved exceptions.

This example implements the privilege constraint pattern for IAM role trust policies. The goal is to identify trust relationships that allow overly broad principals to assume a role. The policy inspects the assume_role_policy document for aws_iam_role resources and looks for wildcard principals in three valid representations: Principal is "*", Principal.AWS is "*", and Principal.AWS is an array containing "*". A wildcard principal allows a broader set of callers than most environments intend to permit. By treating wildcard principals as the prohibited pattern, the rule enforces a safer default and returns a clear result that reviewers can understand quickly.

package compliance.amazon_iam.trust

import future.keywords.in
import future.keywords.contains
import future.keywords.if

# Deny: IAM role with wildcard principal in trust policy
deny contains msg if {
    resource := input.resource_changes[_]
    resource.type == "aws_iam_role"
    is_create_or_update(resource.change.actions)

    policy_value := resource.change.after.assume_role_policy
    policy := json.unmarshal(policy_value)

    stmt := policy.Statement[_]
    stmt.Effect == "Allow"
    has_wildcard_principal(stmt)

    msg := sprintf(
        "[IAM-OPA-2] Resource '%s' has a wildcard principal in its trust policy. Specify explicit account ARNs, service principals, or federated providers instead of \"*\".",
        [resource.address]
    )
}

# Principal is directly "*"
has_wildcard_principal(stmt) if {
    stmt.Principal == "*"
}

# Principal.AWS is "*"
has_wildcard_principal(stmt) if {
    stmt.Principal.AWS == "*"
}

# Principal.AWS is an array containing "*"
has_wildcard_principal(stmt) if {
    stmt.Principal.AWS[_] == "*"
}

is_create_or_update(actions) if { actions[_] == "create" }
is_create_or_update(actions) if { actions[_] == "update" }

When you adapt this example, decide what least privilege means for your IAM trust model. The key design choice is whether your policy checks for a single prohibited pattern or validates trust relationships against an approved set of trusted principals and conditions.

AWS Labs provides IAM Policy Autopilot, an open-source Model Context Protocol (MCP) server and command-line tool that helps generate baseline identity-based IAM policies from application code. That is adjacent to the pattern shown here —IAM Policy Autopilot helps with policy generation, while this example focuses on validating whether IAM role trust policies are scoped appropriately in infrastructure changes.

The following examples show the same operating model in two common CI/CD systems. The syntax changes, but the sequence stays the same: validate, plan, evaluate policy, retain the artifact, and use the result during promotion and approval. These examples assume OPA is installed in your CI/CD environment, the opa-policies directory contains your policy library, and Terraform is configured with appropriate credentials.

GitLab CI

stages:
  - validate
  - plan
  - policy_check

variables:
  TF_IN_AUTOMATION: "true"

terraform_validate:
  stage: validate
  script:
    - terraform fmt -check
    - terraform init
    - terraform validate

terraform_plan:
  stage: plan
  script:
    - terraform plan -out=tfplan
    - terraform show -json tfplan > tfplan.json
  artifacts:
    paths:
      - tfplan.json

opa_policy_check:
  stage: policy_check
  script:
    - opa eval --format pretty --data opa-policies --input tfplan.json "data.terraform.deny"
    - opa eval --format json --data opa-policies --input tfplan.json "data.terraform.deny" > policy-report.json
  artifacts:
    paths:
      - policy-report.json

GitHub Actions

name: Terraform Policy Check
on:
  pull_request:

jobs:
  policy-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3

      - name: Terraform Format Check
        run: terraform fmt -check
      - name: Terraform Init
        run: terraform init
      - name: Terraform Validate
        run: terraform validate
      - name: Terraform Plan
        run: terraform plan -out=tfplan
      - name: Convert Plan to JSON
        run: terraform show -json tfplan > tfplan.json
      - name: Run OPA Policy Check
        run: |
          opa eval --format pretty --data opa-policies --input tfplan.json "data.terraform.deny"
          opa eval --format json --data opa-policies --input tfplan.json "data.terraform.deny" > policy-report.json
      - name: Upload Validation Artifact
        uses: actions/upload-artifact@v4
        with:
          name: policy-report
          path: policy-report.json

In mature delivery workflows, policy results don’t disappear into pipeline logs but are retained as validation artifacts. Those artifacts help reviewers decide whether a change is ready for approval, supports exception handling by showing which controls failed and why, and can stay with the change record for later audit discussions. At a minimum, the artifact identifies the change or pipeline run, the evaluated scope, the policy package or version, the checks that ran, and the pass or fail results.

The first few rules are usually straightforward.The real work starts when the library grows and multiple teams depend on it. Testing includes:

• Positive and negative test cases – Each policy has cases that show valid input and cases that show expected failures.
• Regression coverage – Shared helpers need regression coverage.
• Realistic fixtures – Terraform plan fixtures look like real changes rather than tiny made-up samples.
• Impact analysis – When a rule changes, teams can tell quickly what else might be affected.

If developers stop trusting the results, they stop treating policy as a useful mechanism.

You don’t need broad coverage on day one. A phased rollout works better than an all at once enforcement approach.

Phase 1: Assess and pilot

• Start in advisory mode so teams can see results without being blocked.
• Identify two or three high-confidence patterns such as required metadata, approved Regions, or public exposure restrictions.
• Run OPA against existing pipelines and review the output for accuracy.

Phase 2: Begin enforcement

• Enforce the small set of high-confidence patterns after the output is stable and the failures are useful.
• Integrate validation artifacts into your approval workflow.
• Establish ownership and exception handling processes for shared packages.

Phase 3: Operationalize and expand

• Formalize versioning for shared policy packages.
• Expand pattern coverage based on team feedback and organizational priorities.
• Connect pre-deployment validation with post-deployment monitoring through AWS Config, AWS Security Hub, and AWS Organizations.

Policy as code helps narrow the distance between what an organization says it expects and what its delivery system checks. By implementing these OPA patterns in your CI/CD pipelines, you can build a preventive layer that evaluates infrastructure changes before deployment. With a pattern-based library, validation artifacts, and clear ownership, policy as code becomes a repeatable way to help translate control intent into day-to-day delivery, while AWS governance services continue to provide visibility and monitoring after resources exist.

To learn more about policy as code and AWS governance capabilities, see:

• Contact AWS Security Assurance Services – Get help with your compliance engineering journey
• Open Policy Agent Documentation – Read the official OPA documentation and policy language reference
• AWS Security Hub User Guide – Learn how to aggregate and prioritize security findings
• AWS Well-Architected Framework: Security pillar – Review security best practices for your workloads
• AWS Config Developer Guide – Learn how to monitor and record resource configurations
• IAM Policy Autopilot – An open source command line interface (CLI) and MCP server from AWS Labs that helps generate IAM policies

If you have feedback about this post, submit comments in the Comments section below.

Key Takeaways

• Discovery has been commoditized. Frontier AI models like Mythos and GPT 5.5 are making vulnerability discovery cheap, fast, and broadly accessible.
• The defender's job is to match the speed. Manual triage has lost the throughput race.
• Threat intelligence is the prioritization layer at machine speed. Recorded Future Intelligence observed only 446 actively exploited CVEs in 2025 against approximately 50,000 disclosed — less than 1%.
• Recorded Future's agentic processing plus Autonomous Threat Operations can be the answer. It offers detection signatures in just 31 minutes and automated action across more than 100 integrations, with third-party reach coming soon. Attackers are operating at this speed. Your defenses have to match them.

It’s now a question I get daily: “What is Recorded Future doing about Mythos?”

It's a fair question. Anthropic's Project Glasswing announcement, paired with the vulnerability research benchmarks coming out of OpenAI's GPT 5.5, has made AI-driven vulnerability discovery a board-level topic in a matter of weeks.

To answer that question, first we need to discuss the operational problem defenders actually face and why threat intelligence can be the best way to counter it at machine speed. Then we'll get into what Recorded Future is already deploying to solve it: our agentic processing.

The problem: drowning in signal, starving for context

Even before AI and the news of Mythos’ capabilities and speed, defenders were struggling. Signal volume was outpacing analyst capacity. Coverage gaps widened daily as long-tail vendors and niche platforms went unmonitored. Raw findings arrived without root cause, threat-actor relevance, or vetted remediation paths. Producing one analyst-grade enrichment took hours of senior researcher time. The math didn't work at enterprise scale.

The reality check: 50,000 disclosed, 446 actually exploited

The data point that should anchor any conversation about the AI vulnerability surge: The NVD disclosed approximately 50,000 CVEs in 2025. Recorded Future Intelligence observed only 446 actively exploited in the wild — less than 1%.

Finding vulnerabilities is one thing, but knowing which ones matter, to which environments, against which adversaries, and with which compensating controls already in place is a whole different matter. Forrester put it directly: “The limiting factor in security is no longer the ability and knowledge to find problems — it's the ability to absorb, prioritize, and act on them before adversaries do.” The bottleneck has always been on the absorb-prioritize-act side. The find side was never the problem.

Frontier AI models accelerate the finding side. Threat intelligence is what helps close the prioritization gap on the fixing side.

The prioritization filter: what turns 50,000 into 446

Threat intelligence is operational, not philosophical. It comes down to four signals that distinguish the small fraction of CVEs adversaries actually weaponize from the overwhelming majority that they don't. These four signals are non-negotiable to be able to get to the prioritizing at speed and scale:

1. A live risk score. A composite index of exploitation likelihood and impact, recalculated continuously as evidence shifts. Not a static CVSS rating; a live measure of which vulnerabilities are weaponizable, exploitable in modern environments, and likely to be picked up by threat actors.
2. Active exploitation in the wild. Observed exploitation evidence — not theoretical PoC availability, but documented use against real systems by real actors. Sources include open and dark web telemetry, vendor disclosures, government advisories (CISA KEV catalog and equivalents), and primary research like what Insikt Group® produces.
3. Ransomware actor association. Mapping CVEs to specific ransomware operators and access broker activity. The same vulnerability used by a financially motivated ransomware affiliate against your sector is a different incident than the same CVE in a state-actor toolkit targeting a different region.
4. Sector and campaign targeting. Which threat actors are targeting your industry, which TTPs they're using, which exposures map to known tooling.

Together, these four signals are how you prioritize what actually matters for any given defender.

Recorded Future's answer: agentic processing plus Autonomous Threat Operations

If attackers are moving at Mythos speed, your defenses need to keep up using agentic processing and Autonomous Threat Operations. This is my answer to the question we started with about what Recorded Future is doing about the new world we live in.

Agentic processing is the production system that turns exposure signals into deployable intelligence. The pipeline reads descriptions, vendor advisories, and patch diffs the moment they appear. It produces production-ready detection signatures — documented detection logic, evidence specification, passive fingerprinting strategy. It writes analyst-grade enrichment for every finding — root cause, exploit mechanics, threat-actor associations, prioritized defensive controls with deploy-time and false-positive estimates, validated remediation tasks with acceptance criteria and rollback plans.

It’s end-to-end target: identification to deployment in customer environments in only 31 minutes. Internal averages run lower. No security team operating manual triage workflows is matching that throughput.

That content can reach every relevant control point in your environment through Autonomous Threat Operations (ATO).

ATO turns agentic-processing outputs and correlated intelligence into operational action across over 100 integrations spanning SIEM, SOAR, EDR/XDR, NGFW, vulnerability management, threat intelligence platforms, identity and access management, email and cloud security, GRC, and threat-informed defense. It continuously deploys priority intelligence, runs autonomous threat hunts, pushes detection rules, and takes preventive action without analyst hours spent on manual correlation. The 8-to-12 hours of weekly correlation work most analyst teams perform manually is almost entirely eliminated. The hunting cadence becomes 24/7.

Soon, ATO will do this across your attack surface and third parties, as vendor exposure has been the most common path to breach for the past three years.

The five-stage pipeline that produces all of this — threat signals, intelligent enrichment, validation and verification, structured output, and customer workflow — runs continuously. Production-ready content is in customer environments within minutes of the originating disclosure across every category of threat the platform detects.

Why agentic processing is different, and why your organization needs it

Four things distinguish agentic processing from anything a security team can build manually:

1. Hours → minutes. A complete enriched finding can be produced in minutes, not the hours of manual research the same output used to require.
2. Order-of-magnitude efficiency. Based on Recorded Future R&D findings, per-vulnerability triage runs at 40x the efficiency of manual research effort, enabling coverage at scale your team cannot achieve by hand.
3. Long-tail coverage. Localized vendors, niche platforms, and legacy systems become economically viable to cover at breadth.
4. Always current. Continuous refresh cycles keep intelligence accurate as threats evolve.

These benefits represent the difference between preventing threats pre-attack and absorbing the damage after.

Let’s look at an example of what agentic processing does at machine speed.

React2Shell with agentic processing

Take CVE-2025-55182 — React2Shell, a pre-authentication remote code execution vulnerability in React Server Components. Within minutes of disclosure, agentic processing produced:

1. An Attack Surface Intelligence (ASI) detection signature with documented detection logic, evidence specification, and passive fingerprinting strategy
2. Root cause and exploit mechanics down to the specific code path
3. Active campaigns, threat-actor associations, observed exploitation evidence
4. Confidence-graded indicators of compromise with detection commands
5. Prioritized defensive controls with deploy-time and false-positive estimates
6. Manual validation procedures, remediation tasks with acceptance criteria and rollback plans, and post-remediation verification commands

In this new Mythos age, this type of agentic processing and speed is going to be required as the new baseline.

Beyond vulnerabilities: the same playbook generalizes

Vulnerability disclosure is the most visible trigger for the intelligence-at-speed pattern, but it isn't the only one. The same operational logic applies wherever a new threat signal surfaces and a defender needs to act on it before the adversary monetizes it.

When a brand impersonation site is stood up, the defensive sequence is the same: detection, intelligence enrichment (registrant, registrar, hosting infrastructure, historical campaign association), prioritized defensive controls (takedown coordination, blocking at email and web layers, alerting affected employees), and verification that the takedown landed. Recorded Future's Digital Risk Protection runs this loop continuously across the open, deep, and dark web.

When a stolen credential surfaces in an infostealer log market, Identity Intelligence runs the same pattern: detection of credentials tied to your environment, enrichment with infection context (malware family, device, other credentials in the same log, MFA cookie capture status), prioritized response (force password reset, revoke active sessions, alert the user), and verification.

The pattern is the posture. Apply intelligence at machine speed wherever the adversary is acting, across every category of threat surface. Vulnerabilities are one trigger. The work generalizes. Recorded Future is operationalizing intelligence at machine speed across our four solutions, Cyber Operations, Digital Risk Protection, Third-Party Risk, and Payment Fraud Intelligence.

What this means for defenders

The operational response to AI-driven vulnerability discovery is what separates organizations that contain exposures from those that wake up to incident response calls.

We are seeing customers set up automation to move faster in response to this new reality. A large enterprise in the financial services sector used Recorded Future to transform their vulnerability management workflow. Following a major patching effort across the organization, the team built out automation between their vulnerability scanning and IT service management tools. The result: a streamlined, repeatable process and an estimated weekly time savings of over 20 hours for the team.

We recommend taking these five actions so you can respond as well:

1. Move to autonomous intelligence-led security. Asset inventories are no longer sufficient without knowing if a vulnerability exists, if it is a priority, and what the blast radius is.
2. Compress your disclosure-to-detection cycle to minutes. Manual signature creation runs in days. Adversaries are moving in hours. Whatever your current cycle time, halving it is now baseline.
3. Demand intelligence-led prioritization, not severity scores. CVSS and EPSS describe the universe of vulnerabilities, not which ones are being weaponized against your sector this quarter. Threat intelligence helps you prioritize.
4. Action across the full stack, not just the endpoint. AI-driven discovery surfaces flaws in app code, kernels, libraries, and cloud configurations. Defensive response requires reaching wherever the attacker might use the bug.
5. Apply the same posture across all four threat surfaces. Cyber Operations, Digital Risk Protection, Third-Party Risk, and Payment Fraud all face the same AI-augmented attacker clock speed.

AI-driven vulnerability discovery is here. The big question is whether your systems can operate at attacker speed, with a depth of intelligence that survives executive scrutiny. If the answer isn’t a confident yes, then Mythos and the category behind it have already shifted the math against you.

See it in production. Request a demo to see Recorded Future Intelligence and Autonomous Threat Operations turn a vulnerability disclosure into deployable detection and action across your stack within minutes.