AIToday
AI Safety & AlignmentOpen-Source AIZenn AI/MLPublished: Oct 29, 2026, 06:00 JST

OASM, open-source ASM platform, puts scanners and AI agents behind approval gates

Send on LINE
OASM, open-source ASM platform, puts scanners and AI agents behind approval gates

3 Key Points

  1. What happened

    OASM's developers laid out the open-source design: pull-based Go workers launch connector scanners as isolated Docker containers, and the AI Studio agent runs shell commands in sandbox containers while every tool call passes an approval check.

  2. Why it matters

    Because asset and vulnerability inventories are effectively a map for attackers, the design treats the scanning machinery itself as an attack surface — refusing, for instance, to count fetch tools as read-only since a fetched URL can carry data out.

Not sure about something? Ask the AI

Questions and answers are published on this page.

Summaries like this, every morning.

Context & Analysis

OASM's starting point is a statistic: Japan's National Police Agency counted 123 ransomware victim reports in the first half of 2026, the highest ever for a half-year, with VPN devices still the most common infection route. That is why the platform focuses on continuously inventorying what is visible from the internet — unpatched VPN appliances, open remote desktop, unmanaged subdomains — before attackers do.

The developers say the hard part was never running a scanner but running many different ones safely and continuously, normalizing their output into trackable data, and then letting AI agents work on that data without free rein. The architecture follows from that: pull-based workers that reserve execution slots before taking jobs, one separate bidirectional stream for push messages like cancellation, and scanners packaged as connectors resolved from a manifest.

Much of the design is about what the system refuses to do. Approval requests time out to denial rather than permission, a Redis outage triggers re-asking rather than assuming consent, and tools reachable without going through approval are kept read-only. The developers say this openness is intentional: an asset and vulnerability inventory is close to a perfect map for an attacker, so they want anyone to be able to verify what the tool does inside — which is also why the core is published as open source under oasm-platform/open-asm.

FAQ
How does OASM stop an AI agent from doing something dangerous?
Ask mode only receives tools that read workspace data. Command execution, connector runs and sub-agent launches are only provided in Agent mode, and every tool call goes through an approval check with Manual, Plan and Auto modes.
Where do the AI agent's shell commands actually run?
They are sent to workers, not run on the Core API server. With agent_sandbox enabled, each session gets a container with a read-only root filesystem, all capabilities dropped, and no Docker socket mounted; if Docker is unavailable, it errors rather than falling back to the host.
Why does OASM keep scanners in Docker containers?
A manifest from the oasm-connectors repository defines each connector's image, capabilities and resource defaults, so adding or upgrading a scanner only requires syncing the manifest. Containers run read-only with no-new-privileges and limits on CPU, memory and PID count.
Send on LINE

AI news that matters for your work, delivered every morning.

Pick your industry and the AI tools you use, and get news related to your work every day.

Free · 30 seconds with Google · unsubscribe anytimeWhat is AIToday? →

Ask AI

Ask AI anything about this article. The AI reads this article, earlier AIToday articles, and Wikipedia, and cites its sources. Q&As are published on this page for other readers too.

Questions and answers are published on this page.

Related Articles

Next articleGoogle unveils Gemini 4 Carbon with 'significant leap' in security