Ask a SaaS agent vendor to prove six things: agent identity, scoped credentials, a tool allow-list, a stop path, exportable logs and dated test results. Each has a document to request and a test to run. The yardstick is the Cyber Security Agency of Singapore (CSA) addendum on securing agentic AI, version 1.0, dated 17 June 2026. Its PDF says its measures and controls are voluntary. This is for the CTO or CISO who signs for a SaaS agent and cannot read its code.
Australia's regulator APRA put the gap on 30 April 2026: "Identity and access management capabilities have not yet adjusted to nonhuman actors such as AI agents." (APRA letter, attachment, section "AI threats are increasing, but information security practices are struggling to keep pace".) If your own identity system has not caught up, a vendor's claims are all you have, so each needs evidence behind it.
This is general information, not legal advice. Our guide to agent identity and least privilege covers how to build these controls. This post covers what to demand when someone else builds them. It leaves out how attackers reach an agent and how long to keep logs.
Update, 28 October 2026: We re-checked the status of CSA's addendum, IMDA's framework (still version 1.5) and APRA's letter (still dated 30 April 2026) against their own pages and press coverage. Nothing changed: CSA's page still carries "for public consultation", while the PDF itself is version 1.0 of 17 June 2026, and the 15 October coding-assistant handbook is still its newest related document.
At a glance: six proofs to ask a SaaS agent vendor for
Counts are from CSA's addendum, version 1.0; the choice of six is ours.
What does CSA expect of a company that buys an agent?
The CSA addendum lists 21 controls across four lifecycle stages, from planning to operations. For a SaaS agent it concedes that many sit with the vendor, and tells the buyer to ask for transparency about existing controls and test the claims. It calls itself "not mandatory, prescriptive nor exhaustive" (page 9).
Status first, because the web page and the file differ, and we report both. CSA's web page still says "for public consultation", which ran from 22 October 2025 to 31 December 2025. The PDF's version history (page 4) lists version 0.1 on 22 October 2025 as the release "for Public Consultation" and version 1.0 on 17 June 2026 as the "Official publication of Addendum". On legal weight, the PDF says "These measures and controls are voluntary" (page 10, "Purpose and Scope"). Version 1.0 came 238 days after version 0.1.
On SaaS, the addendum is candid about the buyer's position.
For organisations using Software-as-a-Service (SaaS) agentic AI systems, detailed threat modelling and taint tracing may prove impractical due to limited visibility into third-party system architectures and data flows.
CSA, Securing Agentic AI: An Addendum to the Guidelines and Companion Guide on Securing AI Systems, version 1.0, 17 June 2026, section "Risk Management for SaaS Environments", page 30.
Its answer is empirical: "Red teaming exercises can also be useful for SaaS deployments", and these tests "help validate if security measures or claims by vendors actually protect against real-world threats" (same section, page 30). APRA's letter makes the same point from the supervisor's side. It found "an overreliance on vendor presentations and summaries without sufficient examination of key AI risks" (letter body, paragraph on Boards). Slides are not evidence. Nor is a trust-centre badge, a demo or a certificate that does not name the agent you are buying.
Interactive chart
Eleven of CSA's 21 agentic AI controls concern how the agent is built
Number of controls in version 1.0 of the addendum, by lifecycle stage.
Planning and design: 1 control. Development: 11. Deployment: 4. Operations and maintenance: 5. Total 21.
| Stage | Controls |
|---|---|
| Planning and design | 1 |
| Development | 11 |
| Deployment | 4 |
| Operations and maintenance | 5 |
The count shows where a buyer can push. You cannot inspect how the agent is built, and eleven controls sit there. You can still test their effects from outside: an out-of-scope request, an unlisted tool, a timed stop.
Which six proofs should a CTO or CISO ask for?
Ask for six proofs: agent identity, scoped credentials, a tool allow-list, a stop path, logs and eval results (the dated record of tests run on the agent). The first three limit damage. The last three speed up detection and repair. The six are our selection from CSA's 21, not CSA's own list.
Where the six proofs sit around one agent call
Solid green is a call that is allowed. The oxblood box is a call the allow-list refuses.
Each control has a document the vendor can hand over and a test you can run. Weigh the test above the document: a vendor can write a document without it being true. The tabs give both.
1. Agent identity
Ask: does each agent, or class of agent, have its own identity, and who is accountable for it?
Proof that counts: an export of the agent registry with one ID per agent or class, an accountable owner, and whether it acts alone or for a named user.
Your test: trigger one action in your test account and find the agent ID on it in your own audit view. An account shared across unrelated agents or agent classes fails this test; CSA's wording allows one identity per agent class.
Sources: CSA addendum, section 2.2.2 and control 2.6; IMDA framework v1.5, "Agent identity".
2. Scoped credentials
Ask: what permissions does the agent's token hold in our account, how long does the token live, and who can widen it?
Proof that counts: a scope list you can read, the token lifetime, a written statement that the agent cannot change its own privileges and holds no admin rights by default, and how often permissions are reviewed for drift.
Your test: ask for an action outside the stated scope. It should be refused, and the refusal should be logged under the agent's ID.
Sources: CSA controls 2.6, 2.8 and 4.3 (periodic least-privilege reviews); IMDA v1.5, "Authorisation".
3. Tool allow-list
Ask: which tools, connectors, commands and outside web addresses can the agent call, and who approves an addition?
Proof that counts: a written list with a change history, and notice to you when it changes. For tools served over MCP (the Model Context Protocol, a common way to plug tools into agents), proof that a server cannot quietly redefine a tool.
Your test: have the vendor attempt a call to an unlisted tool in a test account. It should fail and appear in the log.
Sources: CSA controls 2.6, 2.7 and 3.3; IMDA v1.5, tool restrictions.
4. Stop path (kill switch)
Ask: how do you stop one agent, then every agent in our account? Who may trigger it, including us, and what happens to actions in flight?
Proof that counts: a written procedure that names who can trigger it, what it revokes, how work falls back to people, and the date of the last drill.
Your test: ask the vendor to trigger the stop while a task runs in a test account, then compare the stop time with the last logged action under that ID, using your own log's clock. Record the gap in seconds. No source sets a target, so you set it.
Sources: CSA control 4.3 (circuit-breakers) and the enterprise-scale controls box in section 4.2 (revoking agent access); IMDA v1.5, "Continuous testing and monitoring"; APRA letter, 30 April 2026.
5. Logs you can export
Ask: can we export every prompt, response and tool call, tagged with the agent's ID, into our own monitoring?
Proof that counts: a sample export, the field list (CSA suggests agent actions, inputs and outputs, errors, timestamps and identifiers that link steps), the retention period, and a plain account of what makes the entries tamper-evident, such as a write-once store or a hash chain. You cannot test that yourself, so ask which independent report covers it and treat it as a claim until you have one.
Your test: run one scripted task, find it in the export, and check that the agent ID, the tool and the times match what you saw happen.
Sources: CSA control 4.3 and the enterprise-scale controls box in section 4.2; IMDA v1.5, "Continuous testing and monitoring".
6. Eval results
Ask: what tests were run on this agent, on which model and prompt version, how many times, what failed, and when are they re-run?
Proof that counts: a dated report that names the versions, covers whole workflows and adversarial cases, shows repeated runs and lists failures. A vendor report with no failures is a brochure.
Your test: run a short set of your own tasks, including some the agent should refuse, before you sign and again after each model change.
Sources: CSA control 3.2; IMDA v1.5, "Before deploying, test agents"; APRA letter, supplier risk section.
Illustrative example: a vendor says its agent "follows least privilege". That is an assurance. Ask for the permission list of the token the agent uses in your account. If it includes delete rights on records the agent only reads, you have found the gap.
How do identity, credentials and tool lists limit the damage?
Together they cap what an agent can do and tie every action to it. CSA links them. It says to treat agents as non-human identities, to issue scoped credentials, and to whitelist what they may run. If one is missing, the other two lose much of their value.
On identity, CSA suggests "unique identities per agent or agent class to limit information and tool access specifically to the roles of the agent(s)" (section 2.2.2, page 17). The IMDA framework (version 1.5, 20 May 2026) is more specific. An agent's identity should be unique and cryptographically verifiable, tied to a supervising human or department, recorded as acting alone or for a named person, and "catalogued and centrally managed".
On credentials, CSA says to "use time-bound (just-in-time) or one-time-use credentials where possible" (control 2.6, page 40) and to "not allow agents to modify privileges" (control 2.8, page 43). IMDA adds a rule worth putting in a contract: a person "should not be able to set permissions for the agent greater than what the human user is himself authorised to do". Ask the vendor to show the cap.
On tools, CSA says to "create a whitelist of commands that agents are allowed to run autonomously" and to "deny execution of all other commands" (control 2.7, page 42). It adds a whitelist for outward network access and a check that an MCP server "has not silently redefined their tools" (control 3.3, page 47). This limits what a planted instruction can do; our post on containing the agent covers that threat.
What should a stop path, the logs and the test results show?
A stop path, an exportable log and dated test results show whether the other three work. Neither CSA nor IMDA uses the words "kill switch", so ask in their terms: circuit-breakers, revoking agent access, stopping the workflow, and fallback. If the vendor cannot name its version of each, it probably has none.
For the stop path, CSA says to "apply circuit-breakers that freeze propagation when anomalous behaviour is detected, and implement human authorisation for release" (control 4.3, page 53). For enterprise setups it adds "processes in-place to revoke agent access when anomalous access is detected" (section 4.2, enterprise-scale controls box, page 34). IMDA says to "stop agent workflow and escalate to a human supervisor". APRA asks boards for "clearly defined triggers" so action is timely (letter body, paragraph on Boards), and says that where AI supports critical operations "credible fallback processes are required" (attachment, section "AI threats are increasing, but information security practices are struggling to keep pace"). Only a drill shows whether any of that works. For the fallback side, see agent business continuity.
For logs, CSA says to "implement immutable, tamper-evident audit logs that capture prompts, responses, and tool invocations" (control 4.3, page 53), to tag every call "with the correct digital ID" (section 4.2, enterprise-scale controls box, page 34), and to stream middleware logs into a SIEM (a security information and event management system, the tool a security team watches). Prompt logs hold personal data, so agree the retention period in the contract. Our system of record post sets out the clocks, and the audit trail guide lists what one record must answer.
For test results, CSA wants behavioural testing against benchmark datasets, with "human evaluators" verifying the results (control 3.2, page 46). IMDA says testing should run "at scale and across varied datasets" and "multiple times to check for stability", because agent behaviour varies from run to run. APRA found "limited evidence of specific provisions addressing audit rights, model updates and deviations, incident notification or changes to data handling" in supplier contracts (attachment, section "Supplier risk management is in place, but supplier concentration and opacity present challenges"). So tie the eval record to a notice duty: when the vendor changes the model, it re-runs the tests and tells you. Our vendor due-diligence post has wording to adapt.
Who asks for what, and what is only guidance?
None of these sources is binding law on a Singapore company. CSA's addendum is voluntary, IMDA's framework is guidance, and APRA's letter covers APRA-regulated entities in Australia only. They agree on substance and differ in detail: CSA and IMDA name tool whitelists, and APRA's letter does not address logging.
| Document | Status | Date | Addressed to |
|---|---|---|---|
| CSA addendum | Voluntary, per its PDF (page 10) | Version 1.0, 17 June 2026 | Owners of agentic AI systems |
| IMDA framework | Governance framework, "a living document" | Version 1.5, 20 May 2026 | Organisations deploying agents |
| APRA letter | Supervisory expectations | 30 April 2026 | APRA-regulated entities only |
| CSA coding-assistant handbook | Guidance, interactive | 15 October 2026 | Security practitioners and risk owners |
The matrix shows how each of the six appears in the first three documents. Filter it to the rows where they differ.
Coverage matrix
Where each source asks for each proof
Filter to the rows where the sources differ.
| Proof | CSA addendum v1.0 | IMDA framework v1.5 | APRA letter |
|---|---|---|---|
| Agent identity | Unique identity per agent or class (2.2.2, 2.6) | Unique, accountable, catalogued | Notes IAM has not adjusted to AI agents |
| Scoped credentials | Scoped, short-lived, no agent admin (2.6, 2.8) | Scoped, time-bound, least privilege | Asks for strong privileged access management |
| Tool allow-list | Whitelist commands, network, MCP (2.6, 2.7, 3.3) | Least-privilege tools; trusted servers only | Not named |
| Stop path | Circuit-breakers; revoke access (4.3) | Stop, halt, terminate, fall back | Defined triggers; fallback processes |
| Logs you can export | Tamper-evident logs of prompts and tool calls (4.3) | Log and trace each step | Logging not addressed |
| Eval results | Benchmarks, adversarial tests, red teaming (3.2) | Test whole workflows, repeatedly | Notes testing gaps; asks continuous validation |
Key: named as a control or practice · related point, not the control itself · not addressed
Origin Pi's reading of CSA (17 June 2026), IMDA (20 May 2026) and APRA (30 April 2026). Control numbers are CSA's. Not an audit standard.
The newest document, CSA's Security Assessment Handbook for Agentic AI Coding Assistants, says it maps threats and tiered controls drawn from the addendum. We have read only its summary page, not the full handbook. For a coding agent, ask which tiers the vendor meets.
How ready is your vendor file?
Count what you hold, not what you have been told. Tick an item only when you have the document or have run the test.
Scorecard
Vendor proof scorecard: six controls, 14 items
Tick an item only when you hold the document or have run the test. Heavier items count more. A guide, not an audit. Nothing you enter leaves your browser.
- How the score works. Each item shows its points, 32 in all. Your score is the points you tick divided by 32, as a whole-number percentage.
- 0 to 39%: Assurances only. You hold promises, not proof. Ask for the heaviest missing items before any data moves.
- 40 to 74%: Partly evidenced. Some proof is on file. Close the heaviest gaps, then run the tests in a test account.
- 75% and above: Evidence on file. Repeat the tests after each model change and review the file each quarter.
Weights are illustrative and total 32 points; each item shows its own. The percentage is points ticked divided by 32, rounded to a whole number (for example, 16 of 32 points is 50%). Heavier items are the tests you run yourself and the proofs that limit damage; a document alone is easier to fake. A design check, not a compliance test.
Where Origin Pi stands
We design agent systems so that these six answers exist before launch. In our agent-ready layer, each agent has its own identity, bounded permissions and a fixed tool list. A confirm step puts a person in front of risky actions, an audit trail records every call, and a stop path is designed in.
For a vendor you already use, the same questions show where to add your own control: a narrower credential, a gateway that logs every call, or a person approving the action.
This week, take the agent in your stack with the widest reach and send its vendor requests 1 and 2: identity and credentials. Those answers decide how much the other four can protect you.
Take the data with you
Every figure in this post is in one table, with its source, source date and the date we read it. If you reuse either file, please cite this post.
