Anthropic has only made the model available to a small circle of technology companies so far. Independent assessments do not exist. All claims come from Anthropic itself, and the media buzz carries unmistakable hype. Whether Mythos is truly as powerful as claimed remains to be seen.

What holds true regardless of Mythos: AI systems are getting more capable by the day. Mythos is not an outlier. It is another signal. Behind it lies a structural shift that has been underway for some time.

The Structural Shift

The balance of power between offense and defense in cybersecurity has been shifting for years. Attacks became cheaper, automation lowered the required expertise, while defenders scaled linearly with whatever budget they had. OWASP calls this imbalance asymmetric warfare.

Offensive AI brings together three things that did not previously coexist: it adapts, it is efficient, and it scales almost without limit. A human attacker can probe a system in a handful of ways at once. An AI-powered system can approach the same target from a thousand angles simultaneously, at the same quality, without fatigue, without a learning curve.

The attack surface is not limited to AI systems themselves. The entire existing digital infrastructure is in play: web applications, APIs, internal systems, supply chains. The pace is accelerating: the window between a vulnerability being discovered and being exploited is shrinking toward zero. What used to take weeks will soon happen in hours.

Good Architecture Helps, but Is Not Enough

Isolation, network segmentation, zero trust: for organizations, these concepts are nearly indispensable today. They segment the attack surface, slow down lateral movement, and make attacks more expensive. Strongly recommended.

But ultimately, this alone does not protect. The higher the effort required, the higher the potential reward tends to be. Anyone who believes they can rest on their architecture without constantly rethinking it underestimates how adaptive modern attackers have become.

Why This Matters Now

What does this mean in practice for those responsible inside organizations?

Most of an enterprise IT landscape is not built in-house. It runs on third-party products. Every external piece of software, every library, every SaaS integration extends the attack surface. Application teams and product managers carry direct responsibility: ensuring that all vulnerabilities in deployed products are known and resolved before they are exploited is becoming a baseline requirement. The same applies to the development process itself: code reviews, static analysis, and dependency scanning are no longer optional.

As the attack surface grows, so does the workload of those who monitor it. For security teams, the focus in vulnerability management shifts fundamentally. Systems need to be understood holistically; application owners should have a playbook for immediate compensating measures. Vulnerabilities that individually carry low severity can be devastating in combination. And that combination is becoming far more likely through AI. The question is no longer which gap to close first, but how fast it can be closed. Automated detection provides the critical head start. Those who spot anomalies early can respond before an attack escalates. Those who do not will find themselves in a race they structurally cannot win.

Operational measures alone are not enough when the underlying risk model no longer holds. CISOs and risk managers need to rethink their classical approach. CVSS-based prioritization breaks down when the exploit probability for every known vulnerability approaches 1. The range of possible incidents grows wider, estimates become less reliable, and residual risks that were previously deemed acceptable no longer are. This needs to be communicated before it has to be explained in the middle of a crisis.

Act Before Others Do

Those who want to hold their own against AI-powered attackers need comparable tools on the defense side, and the competence to use them. AI-driven attack simulation and automated anomaly detection are not a luxury.

Offensive AI systems are not a future scenario. They are here. The only open question is who acts first: the attackers or us.

Modern agents no longer just follow instructions; they are no longer about automating individual steps. They figure out how to reach a goal, take action, and validate their own results. Useful, but also a risk: an agent running with your user permissions can do anything you can do.

So the question we kept coming back to was: How do we ensure nothing goes wrong despite high autonomy? How do we keep humans in control?

Isolation Is a Good Start, but Not Enough

The standard answer is isolation: VMs, containers, network segmentation, tight permissions. This significantly limits the blast radius and is solid advice we follow regardless.

But in practice, agents need credentials. They need to authenticate against Git repositories, APIs, external services. The usual approach is an access token in an environment variable or config file.

The problem: OpenClaw runs with the permissions of the host user. Anything readable by the user is readable by the agent. And anything readable by the agent can end up somewhere else, not maliciously, but through prompt injection, a compromised model, or simply because the token appears in context and gets processed. Whoever holds a token holds the keys to every service it was issued for.

Isolation reduces the blast radius, but a residual risk remains. As long as the token is within the agent’s reach, it can be exposed. Isolation limits what can happen. It does not stop the agent from seeing the token.

The Fix: Keep the Token Out of Reach

We approached this structurally. Instead of hoping the agent handles credentials responsibly, we made sure it never encounters them. The agent does not communicate with the Git repository directly. It goes through a local proxy running as a sidecar alongside OpenClaw.

From the agent’s point of view, the repository is just a local address. The real hostname and authentication details are never exposed. The proxy injects the auth header into every request automatically.

The token never travels through OpenClaw. It cannot be leaked by a compromised session or extracted via prompt injection. It is simply not there to be found.

How It Works

We run OpenClaw in a Docker Compose setup, which allows us to run Caddy as a sidecar directly alongside it. OpenBao generates the Caddy config at runtime and writes it to a temporary shared volume, accessible only to OpenBao and Caddy, not to OpenClaw. The token stays in the secret store and only appears as an injected HTTP header inside Caddy.

template {
  contents = <<EOT
{
  admin off
  auto_https off
}

http://localhost:9999 {
  reverse_proxy https://your.git.remote.server {
    header_up Authorization "Basic "
    header_up Host your.git.remote.server
  }
}
EOT
  destination = "/proxy/Caddyfile"
  perms       = "0600"
  command     = "caddy reload --config /proxy/Caddyfile 2>/dev/null || true"
}

Architecture Over Policy

The key distinction here is not about trust. We are not asking OpenClaw to behave well with credentials it has access to. We designed the system so it never has access in the first place. That is the difference between policy and architecture.