Ready, Set, Test: IMDA’s New Starter Kit for Testing Agentic AI for Safety and Reliability

Executive Summary

Businesses are increasingly deploying agentic artificial intelligence (“AI“) across different functions, both customer-facing and internal. Unlike generative AI tools which largely produce content, agents can take actions that affect the systems around them with limited human involvement. An agent handling customer enquiries might, for instance, process a refund on its own, while an agent supporting software development might scan code for security weaknesses and then decide which files to modify. The impact of agentic malfunctions can therefore be significant, making testing critical to ensure that agents operate safely and reliably.

Accordingly, on 14 October 2026, the Infocomm Media Development Authority (“IMDA“) announced the new Starter Kit for Testing Agentic Systems for Safety and Reliability (“Starter Kit“). The Starter Kit consolidates emerging best practices, challenges, and experiences of testing agentic AI systems, as a practical reference point for organisations that are getting started with such testing. It provides a four-step structured testing approach with a particular focus on additional testing needs unique to agents. It also illustrates this approach using real-world case studies so that organisations can better contextualise the steps in accordance with their specific needs.

This Update summarises the key points from the Starter Kit and the implications for businesses.

Scope of Application

The Starter Kit focuses on testing for safety and reliability. As such, it covers testing to address common risks involving agents, such as unauthorised or erroneous actions. Conversely, it does not set out to address: (i) general performance and cybersecurity concerns (although references to these are included where relevant); and (ii) other performance-related concerns relating to costs or latency.

It is also important to note that the Starter Kit is aimed at enterprise deployments. Its intended readers include those who build and test agentic systems within organisations or as external testers, as well as compliance and responsible AI teams reviewing how their organisations approach testing. In particular, it focuses on two of the more common archetypes for enterprise deployments: (i) workflow automation agentic systems; and (ii) goal-oriented (but still bounded) agentic systems. 

Further, it is useful to situate the Starter Kit alongside other IMDA guidance. Chiefly, the third dimension of the Model AI Governance Framework for Agentic AI (“Agentic MGF“) recommends testing as one of the technical controls to be implemented across the entire agentic life cycle, and the Starter Kit complements this by providing the practical guidance needed on such testing. In turn, in setting out such guidance, the Starter Kit builds on the foundations established in IMDA’s Starter Kit for Testing LLM-Based Applications for Safety and Reliability which is intended for large language models (“LLMs“), but contains additional elements specific to the testing needs of agentic systems.

Finally, IMDA has positioned the Starter Kit as a living document that will be refreshed as agentic testing matures. Future guidance may extend to other types of agentic deployments and introduce testing approaches tailored to specific sectors or industries.

Contents

The Starter Kit provides the following four-step structured testing approach for adoption:

1. Identifying the relevant risks for testing;
2. Creating realistic and robust tests;
3. Running tests and analysing logs; and
4. Continuously monitoring and re-testing.

Identify Relevant Risks

Broadly, organisations should conduct testing for:

1. Common risks affecting agentic systems, e.g. erroneous or unauthorised actions, data breaches, unfair or biased actions, and disruptions to connected systems, each of which may be caused by routine, benign use, or by malicious, adversarial actions. Some of these common risks for agents also overlap with security risks, e.g. agent goal manipulation, tool misuse, memory poisoning, and privilege compromise. 

2. The effectiveness of human oversight and controls, e.g. whether humans possess sufficient visibility and comprehension of agentic actions, and can step in to stop them if necessary, without being hindered by decision fatigue or automation bias.

Organisations should take the following steps to identify the relevant risks:

1. Prioritising risk scenarios: Organisations should set out the key components, architecture and controls of the agentic system, assess where the risks are, derive specific risk scenarios and prioritise which ones to test, taking into consideration: (i) the agent’s intended purpose, capabilities, failure modes and boundaries; and (ii) how the risks contextualise to the use case, both at the outcome and agent trajectory level.

2. Assessing likelihood and impact: In determining testing priorities, organisations should also assess the likelihood and impact of each risk scenario, taking into consideration: (i) the agent’s domain and use case; (ii) its access to sensitive data and/or external systems; (iii) the scope and reversibility of its actions; (iv) its level of autonomy (e.g. if the system has deterministic and non-deterministic elements); (v) the complexity of the system and task at hand (e.g. if multi-agent systems are involved); and (vi) whether an external party supplies or operates the agentic system.

3. Assuming adaptive adversary: When identifying security risks for testing, organisations should assume an adaptive adversary and not simply test for representative conditions or foreseeable failures.

4. Conducting timely identification: Ideally, risk identification and assessment should be conducted at the design planning stage, when the agentic use case is first selected and the agentic system is designed (i.e. the first dimension of the Agentic MGF). In turn, this assessment will inform which risk scenarios should be prioritised subsequently at the testing stage. Comprehensive and well-defined risk scenarios will better facilitate the production of test tasks and metrics during testing.

Create Realistic and Robust Tests

The agentic test set up typically covers the following key components:

1. Test environment: This is the world that the agent is tested in, which can be simulated or located within development, staging or production environments. It includes all the external systems that the agent can access, e.g. Model Context Protocol servers, tools, underlying data and systems, other agents, records of past decisions and actions, and the human user.

2. Test harness: This is the test orchestrator or pipeline that will: (i) run the tests; (ii) reset them in between runs; (iii) feed or simulate the agent’s memory, context, tasks and available tools; (iv) score the agent’s performance; and (v) record the test logs to enable detailed analysis thereafter.

3. Test suite: This is the test itself, including: (i) the test tasks (i.e. the user’s requests for the agent to complete certain tasks); (ii) the evaluators who will assess how the agent fared against the metrics (e.g. LLM judges or rule-based scripts); and (iii) the metrics used for assessment (e.g. accuracy rates for the agent’s tool calls or adherence to tasks).

4. Agentic system: The design of the agentic system affects the test setup. For example, the model’s context window can affect how the test harness supplies information during tests.

Organisations should observe the following guidance for creating realistic and robust tests:

1. Setting up test environment and test harness:

• • Realistic, progressive testing: While testing should be as realistic as possible, organisations should also ensure appropriate containment based on the agentic system’s potential real-world impact. To this end, organisations should first start testing in contained but realistic environments (e.g. a simulated or sandboxed environment). Once greater confidence is achieved, organisations should then progressively transition towards production environments, while ensuring that the appropriate controls and oversight are in place. The Starter Kit sets out good practices for creating testing environments that are: (i) realistic but simulated; and (ii) robust and contained.
  • Stage-by-stage considerations: Organisations should consider, at each stage, the necessary tools and connections required by the agent, their potential blast radius, the guardrails and sandboxing that can be retained, and the multi-layered safeguards that can be made available as safety mechanisms in case controls fail.
  • Higher-risk changes: In addition, where agents are able to make significant changes to real-world environments, organisations should incorporate both human oversight and continuous monitoring so as to spot any unexpected behaviours that may arise.

2. Setting up logging and observability mechanisms for tests:

• • Agentic trajectory: As agentic systems can complete the same task using varied execution steps, testing should capture the entire agentic trajectory, including both reasoning and actions. To allow behaviour to be effectively reconstructed and assessed, testing should span: (i) the user’s tasks or inputs to the agent; (ii) the agentic system and actions (e.g. agent identifiers, system prompts, skills accessed, reasoning, planning, tool calls, interactions with humans, coordination amongst agents, state changes, and memory or context); and (iii) the eventual outcomes (e.g. outputs to users, artefacts produced, and end-state environments).
  • Relevant information: When ascertaining what should be captured, organisations should understand their use case and consider the behaviours that must be tested or monitored. This, in turn, sheds light on the type of information that will be useful, e.g. system information, agent execution information, business or use case checks, and security-related information.
  • Consistency-related failures: Organisations should also check for consistency-related failure modes, e.g.: (i) claim-action consistency, where an agent claims that it completed an action but did not actually do so; and (ii) plan-action consistency, where an agent prepares a plan for the user’s review but does not actually follow it.
  • Adaptive testing: If organisations or third-party testers have limited or black-box visibility over the agentic system, they should adapt their testing approaches. They should consider the risks to be tested for, and the visibility and information required, and request the necessary access from their agentic system providers.
  • Structured logs: Logs should be: (i) designed around the risks and behaviours undergoing testing; and (ii) structured to support efficient parsing, searching and analysis across the agentic trajectory.

3. Defining test tasks, metrics, and evaluators:

• • Realistic usage and tasks: Testing should reflect realistic usage and tasks. This practice helps to uncover more useful and informative results and guards against simulation awareness (i.e. where agents behave differently because they are alert to signs that they are in simulated environments). For example, organisations can consider: (i) using under-specified user prompts and multi-turn interactions (since users typically engage agentic systems over interactive, longer-horizon tasks); and (ii) inserting prompt injections into the surrounding test environment, not just into the test task.
  • Failure modes, guardrails and interactions: Testing should be contextualised to the use case and should encompass: (i) the failure modes identified from the risk assessment stage; (ii) whether guardrails work as intended, e.g. whether boundaries hold if agents of differing permission levels are chained together in a workflow; (iii) whether human-in-the-loop approvals are appropriately triggered, and coordination and handoffs to other agents are smooth; and (iv) different interaction patterns, e.g. varying personas or topics, and testing for both routine and malicious use.
  • Tools and memory: Different agentic components should be tested and their specific failure modes considered. Newer components may introduce additional failure modes and attack surfaces. In particular, the Starter Kit sets out specific failure modes to be tested for: (i) tools, which agents use to interact with external systems; and (ii) memory, which agents use to complete longer-horizon tasks over multiple turns.
  • Metrics: Metrics should be chosen based on the behaviours and risks that are most important for the use case. For agentic systems, such metrics commonly span the assessment of outcomes, the agentic trajectory, agentic interactions (agent-human or agent-agent), susceptibility to attacks, and operational efficiency. Newer metrics that agents should also be tested for include tool use accuracy, handoff accuracy, and human-in-the-loop rates.
  • Evaluators: Evaluators could involve a criteria-based or checklist-based system, depending on the behaviour under assessment. For example, if there are clear checkpoints or expected actions, the evaluation can be more deterministic in nature, whereas LLM-based graders and human assessment may remain more suited for nuanced assessments.

Run Tests and Analyse Logs

1. Ensuring hygiene when running tests: When running tests, organisations should balance rigour and coverage against practicality, taking into consideration: (i) the various available permutations to be tested; (ii) data and infrastructure issues; (iii) model-harness combinations that should be prioritised; (iv) the size of the context window and the need for testing across longer interactions; (v) testing across multiple runs to account for probabilistic behaviour and expected variance; and (vi) reproducibility of results.

2. Testing systems and components: Organisations should conduct: (i) end-to-end, system-level testing; and (ii) targeted, isolated, component-level testing. Where multi-agent systems are concerned, testing could encompass the system together with individual agents and handoffs. Where individual agents are concerned, testing could encompass each component, e.g. memory.

3. Analysing outcomes and failures: Organisations should assess the outputs and outcomes against an expected ground truth, such as the correctness of the final content or other indicators. Organisations should also analyse failures that occur at increasing levels of depth, such as by breaking down results according to their failure modes, conducting component-level diagnostics, and performing log analysis to understand why the agent acted the way it did (e.g. it achieved the right outcome but took incorrect actions or breached boundaries along the way).

4. Scaling log analysis: Agentic logs serve as critical evaluation artefacts, debugging tools and forensic evidence, but have the tendency to be unstructured and voluminous. Thus, to combat the challenges in analysing each aspect of every trajectory at scale, organisations should consider:

• • Progressive automation: Start small and progressively automate the log analysis, e.g. by identifying the most critical signals for monitoring purposes, using these learnings to develop automated scanners, testing these scanners using representative trajectories, and drilling down once the most important signals can be reliably detected.
  • Chunk logs: If the analysis concerns a particular stage, message type, tool call, or window around an event, the log analysis can focus on these events, as applicable. However, if the analysis concerns the full agentic interaction, this should be comprehensively studied.
  • Human review: It will be helpful to ensure human review at each stage, e.g. during initial exploration, when validating scanners, and when investigating high-impact cases.

5. Taking follow-up actions: Test results and logs can assist with determining whether a system is fit for purpose, meets requirements and respects hard gates or thresholds, and whether there are gaps in the test coverage. If there are material weaknesses, organisations should address and re-test these prior to deployment. If there are residual risks, organisations should explicitly assess, accept and own these in accordance with their risk management processes. 

Continuous Monitoring and Re-testing

While any AI system’s behaviour can shift over time, agents present additional sources of change, as their connected tools and services are updated, and their interactions grow more complex. Therefore, organisations should keep such systems under continuous monitoring after deployment and re-test them periodically.

1. Establishing observability mechanisms: Organisations should set up proper observability mechanisms. Logging and tracing should capture relevant agent actions, tool calls, outcomes and failures in a manner that can be efficiently parsed, analysed and monitored. In turn, these observability mechanisms should enable automated monitoring triggers to sound when identifying abrupt behavioural changes, statistical shifts, and user feedback or observed failures. Such fresh incidents, failure modes and user-reported issues can then inform system fixes and ensure that test suites remain relevant for testing purposes.

2. Auditing human oversight: The effectiveness and accuracy of human oversight over the system should be tested, or at minimum, spot-checked, so that issues such as automation bias and decision fatigue can be identified and addressed.

3. Conducting re-testing exercises: Re-testing should be conducted at relevant junctures, including: (i) scheduled re-tests or spot-checks; and (ii) re-testing after important changes to the system are implemented (e.g. material updates to the relevant models, guardrails, or integrations, significant changes to system prompts, and the addition of new tools or capabilities).

Key Insights

The Starter Kit offers welcome practical guidance for organisations deploying agentic AI and complements the Agentic MGF by translating its recommendation to test agentic systems into concrete steps. Businesses deploying or procuring agentic systems may wish to consider: (i) embedding risk identification even at the design stage so that testing priorities are clear from the outset; (ii) reviewing whether their logging and observability mechanisms capture the full agentic trajectory; (iii) for agentic systems supplied or operated by third parties, ensuring that contractual arrangements provide sufficient access and information for testing, as far as possible; and (iv) establishing processes for continuous monitoring, re-testing and the documented acceptance of residual risks.

If you have any queries on the above, please reach out to our team set out on this page.

For regional Technology, Media & Telecommunications matters, please see Rajah & Tann Asia’s Technology, Media & Telecommunications Practice for more information.