Singapore's handbook for assessing AI coding assistants, and how to use it

On 15 October 2026 the Cyber Security Agency of Singapore (CSA) published a Security Assessment Handbook for Agentic AI Coding Assistants. It is guidance, not a regulation, and it is not specific to any product. It is a worked method for answering a question many security teams are being asked right now: our developers want to run coding agents that read files, run commands and call MCP servers, so what could go wrong, and which controls matter most? The handbook is an interactive web page anyone can open, and its structure is useful well outside Singapore.

What the handbook is

The handbook applies CSA's Addendum on Securing Agentic AI to one kind of system: the AI coding assistant, in two archetypes, IDE-based and CLI-based. It is organised as six tabs: an introduction, a system architecture with trust boundaries, attack paths mapped to MITRE ATLAS tactics and techniques, mitigations, a risk assessment method, and a FAQ.

There is one small inconsistency in CSA's own pages. The announcement says the agency released Securing Agentic AI "in 2025". The handbook dates the Addendum to June 2026, and the Addendum's own page is dated 17 June 2026 and says its public consultation ran from 22 October to 31 December 2025. The 2025 date appears to refer to the consultation draft; the final Addendum is from June 2026.

Six trust boundaries

The architecture tab draws the coding agent in the middle of six trust boundaries:

Boundary	Between the agent and
TB1	the user, whose prompts and permissions it acts on
TB2	the model server that processes every assembled prompt
TB3	remote MCP servers
TB4	local MCP servers with filesystem access
TB5	(via a local MCP server) the sources that server reads
TB6	the sources the agent fetches itself, such as websites and issues

A baseline of attack vectors

The handbook defines its attack vectors by how untrusted instructions reach the agent, not by what happens next:

• T-001: instruction files with malicious prompts in a cloned repository.
• T-002a: a malicious or spoofed remote MCP server.
• T-002b: a legitimate remote MCP server that has been compromised.
• T-003: a trojanised local MCP server package.
• T-004: prompt injection in content the agent fetches, such as issues or documentation.
• T-005: skills with malicious instructions (CLI agents only).
• T-006: agent hooks in a repository's settings.json that run when a session event fires (CLI agents only).

The worked attack chains are carried through to remote code execution, which the FAQ calls the outcome with the widest reach: an attacker who can run commands on a developer's machine can get credentials, code and data from there. Insecure code written by the model is deliberately out of scope: it is a model limitation, not an adversary's action.

The controls, and how they are ranked

The mitigations tab lists 25 controls, M-001 to M-025, each tied to a trust boundary and labelled technical, process or people. Each also has a level:

• Level 0 (14 controls): "fundamental", to be adopted as is.
• Level 1 (10 controls): adopt or adapt to your architecture and risk appetite.
• Level 2 (1 control): good practice, especially for high-risk systems.

The Level 0 list is a reasonable minimum standard for any team running coding agents. It includes detecting malicious content in instruction, skill and hook files before they load (M-001), isolating the agent's environment (M-010), human verification before agent changes and commands take effect (M-011), logs of agent interactions with alerting (M-012), interruptibility (M-015), recoverable copies of what the agent can change (M-016), approval before a new skill, hook or component is activated (M-019), constraints on hooks (M-020), and an allowlist of remote MCP endpoints enforced at the network layer rather than in agent configuration alone (M-021).

Some placements are worth a second look. Restricting credential scope (M-014) and blocking access to sensitive files (M-013) are Level 1, while prompting the agent to flag out-of-scope instructions (M-006) is Level 0. A prompt-based control can fail on any run, as the handbook itself notes when it discusses non-determinism. Many teams will want to treat credential scope as fundamental too, given how much of the damage in real incidents comes from what the agent's environment can reach. The handbook allows exactly this: its controls are reference controls, and equivalent or compensating controls are acceptable if the residual risk is assessed.

M-025, suppressing package install scripts and pinning dependencies, is Level 1. This month's tensorlake npm compromise, which ran at install time and then planted agent hooks in repositories, is a good argument for raising it in your own assessment.

The risk method

The risk tab is the part most teams can reuse directly. It starts with a capability checklist (C1 to C10: filesystem read and write, command execution, network retrieval, remote and local MCP, skills, hooks, repository and CI write, credential access), because what an agent can do decides which vectors matter and how far they reach. Then:

1. Define one scenario at a time.
2. Rate impact on a five-point scale, taking the highest criterion met. The handbook gives no impact ratings per vector, because impact depends on your deployment.
3. Rate likelihood on three dimensions (discoverability, complexity and repeatability) and take the lowest, because an attacker has to satisfy all three.
4. Read the inherent risk from the 5×5 matrix, apply controls, and record the residual risk.

Two notes stand out. For attacks that depend on how the model responds, the handbook scores complexity on how reliably the attack succeeds, not how easy it is to attempt, so an attack that lands only sometimes sits at "Possible" or below. And its residual ratings assume an attended session, with a developer present.

Attended and unattended agents

That last point matters for teams running agents from pipelines, issue assignments or schedules. Three Level 0 controls assume a person is watching: human verification (M-011), interruptibility (M-015) and approval before activation (M-019). For unattended runs the handbook gives substitutes: review moves to a pull request the agent cannot approve or merge; interruption becomes hard timeouts, caps on tool and API calls and independent cancellation; and the permitted skills and hooks are pinned in a source-controlled manifest before the run. It also says an unattended agent should run under its own identity, separate from any developer's account, and that residual likelihood should be reassessed upwards rather than taken from the handbook.

What it means for engineering and security leaders

The handbook gives security teams a shared vocabulary for a conversation that is often vague. "Is this coding agent safe?" becomes a set of specific questions: which of C1 to C10 does it have, which of T-001 to T-006 apply, and which Level 0 controls are in place. That is a better basis for an approval decision, and a better record afterwards, than a vendor questionnaire.

It also makes a point that is easy to miss: the risk depends on deployment more than on the product. The same agent with no MCP servers, no hooks and no credentials has a much smaller attack surface than one with all three.

Practical takeaways

• Fill in the capability checklist for each coding agent you allow, attended and unattended separately.
• Map your current controls to the 14 Level 0 mitigations and list the gaps.
• Decide where you disagree with the levels (credential scope is a good candidate) and write down why.
• For unattended agents, adopt the three substitutes: pull-request review the agent can't merge, hard limits on runs, and a pinned manifest of skills and hooks.
• Allowlist remote MCP endpoints at the network layer, not only in each tool's settings.

For the logging control (M-012), SpanDock receives the OpenTelemetry that tools such as Claude Code, Codex, Gemini CLI and GitHub Copilot send, and, as its getting started guide describes, its dashboard shows every session, tool call, model call, token and dollar. It can also forward the same data to your own backends through destinations. The dashboard is in every plan; forwarding to more than one destination is on Standard and up.