Updated 6 September 2026.
What interested me about ARC-AGI-3 was the work an agent has to do before it knows how to solve the problem. It enters an unfamiliar environment, tries something, observes what changes, and builds an understanding it can use on the next move.
That made me think about cybersecurity. An investigation can begin with a suspicious event and very little understanding of what produced it. The next useful question depends on what the previous one revealed.
I still think that connection matters. But the investment question I want to pursue is more specific: what would let a security team trust an agent to carry that investigation further, and eventually act on what it finds?
I’m interested in the security infrastructure that makes that delegation possible. Better reasoning expands what an agent can attempt. Its access, evidence, and ability to verify a change help determine what a customer can responsibly hand over.
ARC-AGI-3, released on March 25, 2026, gives us a useful way to examine part of this problem. Its interactive games require agents to discover unfamiliar mechanics and winning conditions without task-specific instructions. At launch, the reported frontier-model scores were below 1%. That was a result for those systems under those evaluation conditions, rather than a permanent description of AI’s capabilities. ARC Prize’s launch announcement
The score also needs interpretation. Relative Human Action Efficiency combines level completion with action efficiency. Taking twice the human baseline’s actions yields 25% credit for a completed level; taking ten times as many yields 1%. A low aggregate score therefore isn’t simply a low percentage of problems solved. And action count alone doesn’t tell a customer the time, compute cost, or operational risk of getting a result. Scoring methodology
The benchmark makes adaptation observable. It doesn’t establish that cybersecurity will be the first market to benefit, or that the missing capability cannot be learned through training. Those are separate claims that need separate evidence.
This is also where I would revise my earlier description of an “un-harnessed frontier.” A harness is the software around a model that manages tools, context, and execution. The ARC-AGI-3 paper distinguishes generalization from gains produced by benchmark-specific scaffolding, while explicitly recognizing the economic value of harness research. That distinction matters for interpreting a benchmark. A customer’s concern is whether the complete system performs its job reliably. ARC-AGI-3 technical paper
A model might get much better at deciding which evidence to inspect next. It will still need access to the customer’s current environment, a record of what it inspected, and an enforced limit on what it can change. I would expect those responsibilities to remain important as reasoning improves.
Consider an agent investigating unusual use of a service account. This is a hypothetical example, but it makes the distinction concrete. The agent might examine a deployment, check the account’s permissions, compare recent activity with earlier behavior, and revise its hypothesis as evidence arrives.
Its assignment can be clear while the path through the investigation remains uncertain. The organization decides which systems are in scope and which actions are permitted. Within those limits, the agent needs room to choose useful questions. Permission to investigate an account needn’t include permission to disable it.
The feedback is also less complete than a game’s. Finding no suspicious event might mean that nothing happened, or that the relevant logging was missing. A proposed fix might block an attack path while breaking a legitimate dependency. Even in coding, passing tests only establishes what those tests cover. In security, deciding what the available evidence can support is part of the work itself.
There is already more direct evidence for useful cyber agents than an analogy to ARC can provide. In February 2026, Anthropic described Claude finding previously unknown vulnerabilities in open-source software. Its process included extensive validation and human security researchers checking findings and developing patches. That combination is instructive: capability produced useful discoveries, and additional work made those discoveries actionable for maintainers. Anthropic’s research
The consequences of getting the surrounding infrastructure wrong are equally concrete. In July, Anthropic reported three incidents in which cyber evaluations reached real organizations’ systems. The prompts described a simulation without internet access, but the environment had internet connectivity. Anthropic reported compromises using basic techniques, and said the runs lacked the standard safeguards used in its generally available deployments. The stated scope and the accessible scope had diverged. Anthropic’s incident report
That is why I see the development of cyber agents and the infrastructure governing them as connected opportunities. An agent’s ability to make progress through an unfamiliar environment makes it especially important to enforce where that progress is allowed to lead.
Three areas hold my attention.
The first is preserving an investigation’s evidence. A useful system should retain what was observed, where it came from, which explanations were tested, and what remains unknown. Another agent or a human analyst should be able to check a conclusion against the underlying records. When an account’s permissions change, the system should know which earlier conclusions need another look. That creates a more demanding product problem than storing a conversation history.
The second is testing proposed changes against an environment that represents the relevant parts of production. This is where digital twins interest me. A simulation could help compare an attack path before and after a policy change, or test whether a proposed restriction breaks an important workflow. Its value depends on how faithfully it captures the identities, permissions, services, and behavior involved in that decision. More simulated runs won’t compensate for a missing dependency. A company needs to show where its simulated results hold up in production, and where they don’t.
The third is putting an approved decision into effect with limited scope and a way to check the outcome. An agent could propose tighter permissions, test them, obtain the required approval, and verify the resulting state. Where reversal is feasible, it should be planned before the change. Where it isn’t, the threshold for acting should reflect that.
Policy generation belongs inside that process. Observed behavior can inform a policy, but it cannot establish what the organization ought to allow. AWS already generates policy templates from recorded access activity and asks users to review and customize them. The harder question is whether a proposed policy preserves the intended work while removing unwanted access. A rarely used recovery permission and an unnecessary standing privilege can look similar in a short activity history. AWS’s policy-generation documentation
These opportunities have substantial competition. Microsoft documents security agents with configured identities, permissions, and scoped actions. Google’s reference architecture includes investigation orchestration, persistent context, and stored evidence. Those are meaningful parts of the system I’m describing. A startup needs to explain the important responsibility customers still cannot handle well enough with what they have. Microsoft’s application card, Google’s reference architecture
I would look for that answer in a specific workflow. Perhaps a security engineering team needs to verify access changes across several providers. Perhaps an incident response team needs evidence it can trust across tools and handoffs. The first customer should make the product’s responsibility concrete, including what happens when it gets something wrong.
Specialization may help a team earn that trust. It doesn’t require a separate agent for every job title. The architecture should follow the task, and the business should earn its place through better outcomes: fewer missed findings, less analyst work to validate them, faster verified remediation, or fewer disruptive changes. More autonomous activity by itself tells me very little.
This is where I want to spend more of my investing attention. Security infrastructure is part of AI infrastructure, and cyber agents make the connection particularly tangible. They need both the ability to investigate uncertainty and a dependable system for turning their findings into authorized action.
I’d like to meet founders working on the point where a customer is ready to delegate a consequential task but cannot yet trust the system enough to do it. Understanding exactly what prevents that handoff seems to me like a promising place to begin a company.