Securing AI Agents: From Static Scores to Decisions You Can Act On

An AI agent changes a security review because it can keep acting. It can read information, choose a tool, retain context, and trigger a downstream operation. Assessing the application therefore requires attention to how its authority and environment change over time.

At Tokyo AI’s AI x Risk & Security on 22 January 2026, the programme connected agent red teaming, cyber-risk measurement, identity, and behavioral failure. Eddy Almand’s talk provides a useful starting point: security information becomes valuable when it changes a decision.

A score needs a decision behind it

Almand, CEO and Founder of Almata, distinguishes information from intelligence that reduces uncertainty for a particular purpose. His critique of static cyber-risk scoring is that a count of vulnerabilities or completed controls cannot fully describe an adversary, a changing environment, and the consequences of a dependency failing.

This does not mean patching or control measurement stops mattering. It means a dashboard should help answer a concrete question. Which operation needs tighter control today? Which dependency could interrupt an important service? What new evidence would justify changing an earlier assessment?

Almand proposes attention to change velocity, dependency fragility, shifts in adversary interest, and organizational decision latency. These are ways of asking whether the security process can respond to the circumstances it is meant to manage, rather than merely report a stable-looking number.

Keep evidence and confidence in the architecture

His conceptual architecture connects signal ingestion, evidence adjudication, a structured risk state, and scenario analysis. The adjudication step is significant: sources can disagree, have different confidence levels, or describe different periods. Combining them into a fluent narrative does not resolve those differences.

A risk graph can represent assets and their dependencies, but the decisions built on it still need provenance. An analyst should be able to see why an assessment changed and which assumptions remain uncertain. Almand frames forecasting as warning about elevated instability, not predicting the exact time and target of an attack.

For teams applying agents to security work, that is a useful boundary. An agent can assist with collecting and organizing evidence without being granted authority to treat its own hypothesis as an established incident.

Agent security crosses several kinds of control

The other announced talks broaden this view. Alex Polyakov’s red-teaming topic covers attack surfaces in memory, tools, and context. Jonathan Hope’s programme connects agent identity with software development and purchasing workflows. Mao Parr’s topic addresses behavior that departs from intent, including over-optimization and mistaken tool use.

Together, these themes suggest distinguishing malicious influence, excessive permission, and ordinary task failure. They can produce similar symptoms while requiring different responses. A narrow tool permission may limit impact; it will not necessarily reveal why a recommendation was wrong. A better prompt may improve behavior; it does not establish the identity authorized to make a purchase.

That separation makes review more actionable. The team can ask what the agent may read, what it may change, how long permission lasts, and what evidence a reviewer needs when behavior departs from the intended task.

Foundry’s perspective: review a purchasing assistant as a changing system

Consider an illustrative assistant that gathers supplier information and prepares purchase requests. Its first release could read an approved catalogue and draft a request for a person to confirm. Later, the business might want automatic submission for a limited class of purchases.

That expansion changes the security question. The assistant now has a capability with external consequences. We would examine the provenance of supplier data, the authority behind a request, the limits of the submission tool, and the path for revoking access. Content from a supplier document should remain evidence to evaluate, not instructions that can redefine the assistant’s permissions.

The team can test bounded scenarios: a changed supplier record, contradictory delivery information, a request outside the approved category, or a tool that returns an ambiguous result. For each one, the expected response should be explicit, including when the assistant stops and who reviews the case.

Operational review then looks at changes as well as totals. Has a new integration widened access? Has a recurring failure increased review time? Does an incident require pausing a tool or narrowing a permission? A record of those decisions is more useful than a score with no associated action.

For Foundry Labs’ enterprise AI work, the lesson is to make security part of the operating workflow. The system should provide enough evidence, control, and ownership to change course when its conditions change.

Sources and further reading

This article draws on the AI x Risk & Security programme and the talks identified above. Tokyo AI (TAI) connects researchers, engineers, and industry; explore Foundry Labs’ community work for more context.

Talk materials from Eddy Almand are available upon request. Please use our contact form and include the event title and speaker name.

Speaker profiles

Eddy Almand. Founder and CEO of Almata. His talk approaches cyber risk as an intelligence system. LinkedIn.

Alex Polyakov. Co-founder and CEO of Adversa AI, working on AI security and red teaming. LinkedIn.

Jonathan Hope. Founder and CEO of Keychain, working on digital trust. LinkedIn.

Mao Parr. Co-founder and CEO of datagusto. The talk covers behavioral risk and AI governance. LinkedIn.

All articles