Security Assessment Handbook
v1.0 (2026)

Security Assessment Handbook

Agentic AI Coding Assistants
Introduction
Background and context for this security assessment handbook.

Artificial Intelligence (AI) is being applied across sectors to drive efficiency and innovation. To reap the benefits of AI, users must have trust and confidence that the AI will function as originally intended, and outcomes are secure. To secure AI systems, the Cyber Security Agency of Singapore (CSA) has released the Guidelines and Companion Guide on Securing AI Systems in Oct 2024. The Guidelines are designed for system owners to secure the use of AI throughout its life cycle, and the Companion Guide complements the Guidelines as a useful reference that contains practical measures and controls that system owners may consider implementing.

Subsequently, the advent of Agentic AIAI systems that can independently plan and execute multi-step tasks to achieve a specified objective, using tools and data with minimal human intervention per action. capabilities, which can understand context, formulate plans and take independent actions to achieve specified objectives, also introduces new risks with greater potential for impact given its added capabilities and access to tools and data. As such, CSA has released the Addendum on Securing Agentic AI in Jun 2026 to outline how risks could be identified and assessed based on capabilities of Agentic AI systems as well as practical controls to mitigate relevant risks across the development lifecycle.

Based on the Addendum, CSA has since performed a deep dive into AI Coding AssistantsAI coding assistants that go beyond generating code suggestions. They can plan multi-step tasks, invoke external tools, read and write files, execute commands, and interact with remote services with minimal human intervention per action., which is an agentic AI use case commonly adopted by developers. We leverage the Guidelines and Addendum to develop a security assessment approach of coding assistants, and recommend relevant mitigations associated with their use. By doing so, we intend to help security practitionersProfessionals responsible for assessing, monitoring, and managing cybersecurity risks within an organisation. This includes security engineers, analysts, architects, and risk managers. and developersSoftware engineers and technical staff who build, maintain, or operate systems that use agentic AI coding assistants as part of their development workflow. adopt AI Coding Assistants more securely.

About This Handbook

CSA developed this handbook to apply the Addendum's guidance to a specific agentic AI archetype: the AI coding assistant. It covers the system architecture of common deployments, identified attack vectors with adversarial attack paths mapped to MITRE ATLAS tactics and techniques, and mitigations applicable at each trust boundary.

How to Use This Handbook

This handbook is structured as six sequential tabs. Readers are encouraged to progress through them in order, though each tab is designed to function independently for reference purposes.

Introduction
Establishes the context, coverage, and attack vectors addressed in this handbook. Recommended as the starting point for all readers regardless of technical background.
System Architecture
Presents the trust boundary model for IDE-based and CLI-based coding assistant deployments. Readers unfamiliar with the technical architecture are encouraged to focus on the trust boundaries and the external components that interact with the agent, rather than implementation details. Both archetypes may be operated attended, with a developer present during the session, or unattended, where the agent is triggered by a pipeline event, issue assignment, or schedule. The components and trust boundaries are the same in either case; what changes is the principal on TB1 and, with it, which controls can be implemented as written.
Attack Path
Details each identified attack vector as a step-by-step adversarial chain, mapped to MITRE ATLAS tactics and techniques. Select an attack vector from the left panel to trace the full attack path. The objective of this tab is to convey what the agent can be induced to do under each attack vector, not the technical mechanics of exploitation.
Mitigations
Provides actionable controls mapped to each attack vector and trust boundary, drawn from the CSA Addendum on Securing Agentic AI. This tab is the primary reference for security practitioners and risk owners conducting assessments or defining organisational policy. Controls may be filtered by attack vector or trust boundary to support targeted review.
Risk Assessment
Provides the reference 5×5 impact × likelihood risk matrix and the scoring scales used to rate the severity of each attack vector. Opens with a capability checklist, as the capabilities available to an agent determine which attack vectors are relevant and how far their consequences reach. Consult this tab when assigning or reviewing a risk rating for a specific threat scenario.
FAQ
Answers recurring questions on the scope, content, and application of this handbook, grouped by topic. Useful as a first reference for scoping questions before an assessment begins, particularly where a deployment differs from the two archetypes described here.
Baseline Attack Vectors

The following attack vectors (T-001 to T-006) form a baseline set for IDE-based and CLI-based agentic AI coding assistant deployments. Each vector is defined by the surface through which untrusted instructions reach the agent, not by the consequence that follows, which depends on what the agent is able to do in your deployment. Each is detailed in the Attack Path tab with step-by-step adversarial chains and applicable mitigations. Treat this baseline as a starting point for assessment and extend it with vectors specific to your organisation's deployment, tooling, and threat environment.

T-001
Instruction file with malicious prompts
Malicious prompts embedded in instruction files in cloned repositories direct the agent to execute attacker-defined actions. Applies to IDE and CLI agents.
T-002a
Malicious remote MCP server
A spoofed or attacker-controlled remote MCP server is configured in place of a legitimate one, injecting malicious tool responses into the agent context. Applies to IDE and CLI agents.
T-002b
Compromise of benign remote MCP server
A legitimate, already-trusted remote MCP server is compromised by an attacker who embeds malicious behaviour into its tools, exposing all users without any configuration change on their part. Applies to IDE and CLI agents.
T-003
Compromised local MCP server
A trojanised local MCP server package exfiltrates sensitive files when the coding assistant grants it filesystem access during project initialisation. Applies to IDE and CLI agents.
T-004
Malicious prompts in information sources
Prompt injection payloads embedded in external content (e.g. GitHub Issues, documentation) are fetched by the agent and executed as instructions, planting an executable script that runs automatically on the next commit, or exfiltrating data. Applies to IDE and CLI agents.
T-005
Skills with malicious instructions
Malicious skill packages published to public repositories embed adversarial instructions that, when loaded into a CLI-based coding agent, direct the agent to exfiltrate credentials or establish persistence. CLI agents only.
T-006
Agent hooks with malicious actions
Repositories pre-configured with malicious agent hooks in settings.json automatically execute attacker payloads when a user clones the repo and triggers an agent session event. CLI agents only.
System Architecture
This tab maps the technical components of an AI coding assistant deployment and the trust boundaries that separate them. Understanding the architecture is the foundation for threat modelling: each boundary represents a potential attack surface where trust assumptions can be violated.

How to use: Toggle between IDE-based agents and CLI-based agents to see how the architecture differs. Click any component or trust boundary label to view its description and associated attack vectors. Under Filter by Attack Vector, select a vector to highlight the components it affects.

Filter by Attack Vector: select to highlight affected components

Architecture: Click any component or trust boundary label to view more details
Red-highlighted components are affected by the selected attack vector.
Trust Boundaries: click any label to learn more
🖱️

Click a component or trust boundary in the diagram to view details.

Associated Attack Vectors
Attack Path
This tab provides a step-by-step walkthrough of how each attack vector is executed, from initial access through to impact. Each chain is carried through to a worked outcome, most often remote code execution, because an attacker able to run commands can generally reach the others from there. Where the agent's capabilities differ, the same entry point supports different outcomes, including exfiltration of credentials, tokens and source code, and unauthorised modification of code or configuration. Assess the outcome reachable in your deployment rather than the one depicted. These six vectors form a baseline set, not an exhaustive threat model, and should be extended with vectors specific to your own deployment. Each attack chain is mapped to MITRE ATLAS tactics and techniques, making it suitable for use in threat modelling workshops, red team planning, and security control gap analysis.

How to use: Select an attack vector from the list to load its chain. Click through each numbered step (or use the Prev/Next buttons) to follow the attack progression. The architecture diagram updates to highlight the components involved at each stage. Click the ⓘ icon on any attack vector for a full details panel including applicable mitigations.
Architecture: Active Attack Step
Step 1 of 1
Red-highlighted component or trust boundary is active in the selected step.
Details
Mitigations
This tab catalogues the security controls that reduce the risk of each attack vector. Controls are organised by trust boundary, the architectural layer where the control should be applied, making it straightforward to assign ownership and prioritise implementation.

How to use: Under Filter by Attack Vector, select a vector to see only the mitigations relevant to it. Alternatively, select a label under Trust Boundaries to filter by architectural layer. Expand any table row to see an implementation example. Click the mitigation text to open a full details panel showing applicable threats and context.

Control levels: Each control is categorised into three levels based on criticality, with Level 0 being the most critical controls to implement.
  • Level 0Fundamental mitigation to be adopted as is.
  • Level 1Adopt or adapt meaningfully and sensibly based on architecture and risk appetite.
  • Level 2Best practice that is good to consider, especially for high-risk systems.

Control types: Controls are also classified by implementation type.
  • TechnicalImplemented through tooling, configuration, or system settings.
  • ProcessRequires organisational decisions, policies, or procedures.
  • PeopleDepends on human judgement and action during agent interactions.

How to interpret these controls

The mitigations listed in this tab are reference controls intended to achieve the identified security objective for each attack vector and trust boundary. Organisations may implement equivalent or compensating controls based on their architecture, operating model, and risk appetite, provided the resulting risk is assessed and accepted appropriately. An Attack Vector value of "All" means the control is broadly applicable across attack vectors, not that it is universally mandatory.

Note: Where a reference mitigation is operationally impractical, assessors should document the alternative control, its expected risk reduction, and the resulting residual risk.

Attended and unattended deployments: Three mitigating controls assume an attended deployment, in which a developer initiates the session and is present while the agent works: M-011 human verification, M-015 immediate interruptibility, and M-019 approval before activation. Where a developer is absent, each control shows a compensating substitute in its details panel.

Filter by Attack Vector

Architecture: Click a trust boundary to filter
Green-highlighted trust boundary is selected. Click a TB label to filter the table.
Trust Boundaries: click any label to filter
Mitigation Level Attack Vector Trust Boundary
Risk Assessment
This tab provides the reference risk matrix and scoring scales for rating the severity of the attack vectors identified in this handbook. Combine an impact score with a likelihood score to arrive at a risk rating (Low, Medium, Medium-High, or High) for a given attack scenario.

How to rate a risk

  1. Define the risk scenario. Take one attack vector from the Attack Path tab and describe how the threat event could affect the agent in your environment, including what the agent could be induced to do and the resulting adverse consequence. Assess one scenario at a time. It is useful to first record the capabilities of the agent in your deployment using the Capability Checklist below, as these determine which attack vectors are relevant and how far their consequences reach.
  2. Assess impact. Work down the Impact Scale and take the highest rating where any single criterion is met. Determine the impact based on the potential consequence in your deployment, taking into account the capabilities of the agent, and the assets, systems and data that the agent can access or affect. This is why the handbook does not assign an impact rating to individual attack vectors.
  3. Assess likelihood. Assess the likelihood that the threat event could successfully occur under the conditions of your deployment. Rate the scenario against all three dimensions of the Likelihood Scale and take the lowest of the three, as the attacker must satisfy all three for the attack to succeed. The likelihood ratings shown for each vector in the Mitigations tab provide a starting reference and should be adjusted to reflect your deployment context.
  4. Determine inherent risk. Use the risk matrix to determine the inherent risk rating from the assessed impact and likelihood, before taking controls into account.
  5. Apply recommended mitigations and determine residual risk. Apply the relevant controls from the Mitigations tab and reassess the likelihood and impact, where applicable. Use the risk matrix to determine the residual risk and record both the inherent and residual risk ratings.
Capability Checklist
The capabilities available to an agent do not necessarily correlate with the environment in which it runs. For example, an agent integrated into a code editor that can execute commands and load third-party extensions may be exposed to more attack vectors than a command-line agent without those capabilities. Recording the capabilities of the agent in your deployment provides a basis for assessing impact below.
Code Capability What to determine Related attack vectors
C1 Filesystem read Which paths the agent can read, and whether it can reach beyond the project directory into home directories, credential stores, or other repositories.
Related controls
  • M-001Detect malicious content in instruction files, skill files, and hook configurations before they are loaded
  • M-010Isolate the agent's operating environment to contain the impact of malicious actions
  • M-013Block agent access to sensitive files and folders except where a task requires it
 T-001
C2 Filesystem write Which paths the agent can write to. Pay particular attention to places another program later runs code from, such as the repository's own .git/hooks directory, build scripts, or pipeline definitions.
Related controls
  • M-011Human verification before agent-initiated file changes or commands take effect
  • M-016Maintain recoverable copies of files and repositories the agent can modify
  • M-018Detect vulnerabilities in agent-generated code before it is deployed
 T-004
C3 Agent command execution Whether the agent can run commands on the host, and whether those commands are confined to an isolated environment or reach the developer's machine directly.
Related controls
  • M-010Isolate the agent's operating environment to contain the impact of malicious actions
  • M-011Human verification before agent-initiated file changes or commands take effect
  • M-012Maintain logs of agent interactions and executed actions, with alerting on anomalous activity
  • M-015Immediate interruptibility of the agent at any point during execution
 T-001, T-002a, T-002b, T-003, T-005, T-006
C4 Network retrieval Whether the agent can fetch external content itself, and whether it is limited to an approved list of destinations.
Related controls
  • M-008Constrain which information sources the agent may search and retrieve from
  • M-009Restrict external resources the agent loads to approved, authenticity-checked sources
  • M-024Sanitise content the agent fetches directly before it enters the LLM context
 T-004
C5 Remote MCP connection Whether the agent can connect to MCP servers over the network, who approves a server before it is added, and whether developers can add their own.
Related controls
  • M-002Detect suspicious behaviours in MCP server tool descriptions before the server is installed or connected
  • M-003Monitor remote MCP tool execution and block suspicious responses or configuration changes
  • M-021Constrain which remote MCP server endpoints the agent may connect to
  • M-022Verify a remote MCP server's identity, credentials, and message integrity before trusting its responses
 T-002a, T-002b
C6 Local MCP with host access Whether the agent can run MCP servers as local processes, what privileges those processes hold, and what they can reach on the host on their own.
Related controls
  • M-002Detect suspicious behaviours in MCP server tool descriptions before the server is installed or connected
  • M-004Monitor local MCP tool execution and block suspicious responses or configuration changes
  • M-007Detect vulnerabilities in code and configuration pulled from local or central repositories
  • M-023Sanitise content retrieved via local MCP servers before it reaches the agent
 T-003, T-004
C7 Skill or extension loading Whether third-party skills or extensions can be loaded, where they come from, and whether someone must approve them first.
Related controls
  • M-001Detect malicious content in instruction files, skill files, and hook configurations before they are loaded
  • M-009Restrict external resources the agent loads to approved, authenticity-checked sources
  • M-019Human approval before a new skill, hook, or external component is activated
 T-005
C8 Agent hooks Whether settings carried inside a cloned repository can make the agent run commands automatically when a configured event occurs, such as the start of a session, a tool call, an approval decision, or a change to a watched file. Some events are changes in the workspace rather than points in the agent's own run, so a hook can fire without the developer interacting with the agent.
Related controls
  • M-001Detect malicious content in instruction files, skill files, and hook configurations before they are loaded
  • M-019Human approval before a new skill, hook, or external component is activated
  • M-020Constrain hook execution and access to limit the impact of malicious or compromised hooks
 T-006
C9 Repository and CI write Whether the agent can commit, push, open pull requests, or modify pipeline definitions, and whether branch protection excludes the identity under which it runs.
Related controls
  • M-011Human verification before agent-initiated file changes or commands take effect
  • M-016Maintain recoverable copies of files and repositories the agent can modify
  • M-018Detect vulnerabilities in agent-generated code before it is deployed
 Increases impact across all vectors
C10 Credential access Which credentials the agent can read or use, what access those credentials grant, and how long they stay valid.
Related controls
  • M-013Block agent access to sensitive files and folders except where a task requires it
  • M-014Restrict the scope of credentials issued to the agent to the minimum required
 T-003, T-005
Risk Matrix (Impact × Likelihood)
Read impact rows top-to-bottom (Catastrophic → Negligible), likelihood columns left-to-right (Rare → Almost Certain). The score is Impact × Likelihood; the label indicates the rating band.
Likelihood →Impact ↓ Rare
(1)		 Unlikely
(2)		 Possible
(3)		 Likely
(4)		 Almost Certain
(5)
Catastrophic (5) Medium5 Medium-High10 High15 High20 High25
Major (4) Low4 Medium8 Medium-High12 High16 High20
Moderate (3) Low3 Medium6 Medium9 Medium-High12 High15
Minor (2) Low2 Low4 Medium6 Medium8 Medium-High10
Negligible (1) Low1 Low2 Low3 Low4 Medium5
Low Medium Medium-High High
Impact Scale
Each impact level is defined by one or more descriptive criteria. Any single criterion is sufficient to justify the rating. Rate impact against your own deployment, taking into account the capabilities of the agent, and the assets, systems and data that it can access or affect.
Rating Score Description
Catastrophic 5 Could cause exceptionally grave harm, including risk to human safety or the loss of critical services
Could cause severe ongoing impact on the organisation's or multiple organisations' ability to perform their primary functions
Could cause severe reputational, financial, or commercial damage to the organisation or to the parties that depend on it
Could cause severe breach of laws, regulations, or contractual obligations, or major litigation against the organisation
Major 4 Could cause serious harm to the organisation, its customers, or third parties that depend on it
Could cause serious ongoing impact on one or more business functions' ability to operate
Could cause serious reputational, financial, or commercial damage to the organisation
Could cause serious breach of laws, regulations, or contractual obligations, or litigation against the organisation
Moderate 3 Could cause harm to the organisation or its interests
Could adversely impact the organisation's ability to perform its primary functions
Could cause reputational, financial, or commercial damage to the organisation
Could cause breach of laws, regulations, or contractual obligations, or litigation against the organisation
Minor 2 Could cause difficulties or undesirable consequences to the organisation
Could cause difficulties in the organisation's ability to perform its primary or secondary functions
Could cause inconvenience to a limited number of users in the organisation
Negligible 1 Has no impact on the organisation's ability to perform its primary or secondary functions
Has no impact to anyone
Likelihood Scale
Each likelihood level is defined across three dimensions: Discoverability, Complexity, and Repeatability. An attacker must satisfy all three, so the rating is set by the binding constraint: score each dimension, then take the lowest. Complexity of exploit is scored by how hard it is to mount an attack that reliably achieves its objective, not by how few steps are needed to attempt one.
Likelihood Discoverability of exploit Complexity of exploit Repeatability
Almost Certain (5) Vulnerabilities can be discovered from publicly available information Trivial, a straightforward attack achieves its objective on essentially every attempt with no tailoring The attack can be repeated any time
Likely (4) Vulnerability can be discovered through functional use of the application Reliable once the attack is placed correctly and lightly tailored to the target's setup; minimal tuning The attack can be carried out frequently
Possible (3) Vulnerability can only be discovered with technical specification of the application Needs specific conditions, placement, and a few attempts to land, succeeds sometimes, not every run The attack can only be carried out at specific times
Unlikely (2) Vulnerability can only be discovered through technical analysis of the application Requires obfuscation (Unicode / zero-width, encoding) or an attack hand-tuned to one specific agent, tool, or configuration The attack can only be carried out infrequently
Rare (1) Vulnerability can only be discovered through source code analysis of the application Only works via multi-step chaining with other exploits or a precise, tightly sequenced setup The attack can only be carried out once

Non-determinism check: Where an attack depends on how the model responds to attacker-supplied content, the outcome is probabilistic, and the same attack can succeed on one run and fail on the next. This is why Complexity is scored on reliability of success rather than ease of attempt: an attack that only lands occasionally sits at Possible (3) or below, not Almost Certain. As more evidence accumulates through repeated trials, revise the level up or down accordingly.

Unattended deployments: the residual likelihood ratings assigned to each attack vector assume an attended deployment with a developer present during the session. Where an agent runs unattended, three mitigating controls are replaced by weaker compensating substitutes: M-011 human verification, M-015 immediate interruptibility, and M-019 approval before activation. Residual likelihood should be reassessed upward accordingly rather than inherited from this handbook.

Frequently Asked Questions
Common questions about the scope, content, and application of this handbook.
About This Handbook
Who is this handbook for?
This handbook is intended for security practitioners and developers who are assessing, deploying, or securing agentic AI coding assistants in an enterprise environment.
How does this relate to the CSA Addendum on Securing Agentic AI?
This handbook is intended to be read alongside the CSA Addendum on Securing Agentic AI, which provides guidance on securing agentic AI across different system types. This handbook applies that guidance to a specific archetype (the agentic AI coding assistant), with trust boundaries, attack vectors, and mitigations specific to that deployment context.
Does this apply to all AI coding assistants, or only specific products?
The handbook is applicable to agentic AI coding assistants that can invoke external tools, read and write files, execute commands, and interact with remote services. The guidance is not specific to particular products. The two deployment archetypes (IDE-based and CLI-based) are representative of how most commercial and open-source agentic AI coding assistants are deployed today.
Will the attack vectors be updated over time?
Yes. T-001 to T-006 form a baseline set: a representative, currently identified group of attack vectors, not an exhaustive threat model. As deployment practices evolve and attacker techniques mature, additional vectors may be identified and included.
Technology and Scope
What is the difference between an IDE-based and CLI-based coding agent?
IDE-based coding agents are integrated directly into a developer's code editor, providing assistance within the editing environment. CLI-based coding agents operate from the terminal and have direct access to the local filesystem, shell commands, and agent hooks. CLI-based agents generally have a wider attack surface due to their deeper system access and support for skills and hooks, which introduce additional extension points not present in most IDE-based deployments.
Why is insecure code generation not included as an attack vector?
Insecure code generation arises from the limitations of the underlying LLM. It is an outcome of how the LLM was trained, not the result of an adversary exploiting the system. This handbook focuses on adversarial attack vectors, where an attacker deliberately manipulates the agent's inputs to cause harmful actions.
Why do the attack chains end in remote code execution?
The attack vectors are classified by the surface through which untrusted instructions reach the agent, not by the consequence that follows. Each chain ends at remote code execution because it is the outcome with the widest reach. An attacker capable of running commands on a developer's machine can obtain credentials, source code, and data from there. The same entry point supports other outcomes where the agent's capabilities allow them, such as exfiltration of credentials and tokens, or unauthorised modification of code and configuration. These outcomes are consequences of the vectors listed, not separate vectors.
Are all attack vectors equally likely to be exploited?
No. Each attack vector has an assessed likelihood of exploitation before and after mitigations are applied, visible in the Mitigations tab when filtering by a single attack vector. In general, vectors that rely on a developer cloning a malicious repository or connecting to an attacker-controlled server have a higher likelihood than those requiring compromise of an already-trusted service.
Deployment
Does this apply to cloud-hosted deployments, on-premises deployments, or both?
Both. The attack vectors and trust boundaries described in this handbook apply regardless of whether the underlying LLM is accessed via a cloud API or hosted on-premises. The key factors are the capabilities of the coding agent (what tools it can invoke, what files it can access) and the trust boundaries in the deployment, not the hosting model of the LLM itself.
My organisation does not use MCP servers. Which attack vectors still apply?
T-002a, T-002b, and T-003 (the three MCP-related attack vectors) would not apply directly. T-001 (Instruction file with malicious prompts), T-004 (Malicious prompts in information sources), T-005 (Skills with malicious instructions), and T-006 (Hooks with malicious actions) remain relevant depending on the features enabled in your deployment. You can use the Architecture tab to filter by attack vector and see which components are affected.
Does this handbook apply to agents that run without a developer present, such as CI/CD-triggered or scheduled agents?
Yes. An agent triggered by a pipeline event, an issue assignment, or a schedule uses the same components and crosses the same trust boundaries as one a developer runs at a workstation, so every attack vector still applies. It should run under its own identity, separate from any developer account, so that what it is allowed to do can be limited and withdrawn on its own.

However, three mitigating controls assume a developer is present and cannot be implemented as written where one is not. Select any of them to open the control in the Mitigations tab, where its full compensating substitute is shown.
Because these three carry a substantial share of the risk reduction, the residual likelihood ratings in this handbook assume attended operation and should be reassessed rather than inherited.
Filtered by