Agent Harness AI Governance in Singapore: Where MAS and IMDA Expectations Actually Land
Singapore's agentic-AI rules don't regulate the model — they regulate what the agent is allowed to do. That makes the harness (tool permissions, approval gates, logs, kill switches) the layer where supervisory expectations become code. This page maps one to the other.
Key takeaways
- MAS's proposed AI Risk Management Guidelines (consultation, 13 Nov 2025) explicitly cover Generative AI and AI agents, and apply to all financial institutions proportionately.
- IMDA's Model AI Governance Framework for Agentic AI (Jan 2026, updated May 2026) frames agent risk around bounding autonomy, human accountability, lifecycle technical controls, and end-user responsibility.
- Both instruments converge on controls that live in the harness, not the model: access limits, approval checkpoints, logging, override/kill mechanisms, change control.
- Using a third-party harness does not transfer accountability — it adds a third-party AI risk line the deploying organisation must evidence.
- The practical gap is evidence: most teams can describe their agent controls; few can produce a reproducible trace an examiner would accept.
- Model
- The LLM producing tokens. Stateless; has no permissions of its own.
- Agent harness
- The runtime around the model: planning/loop control, tool registry and invocation, identity/credentials, memory/context, guardrails, approval gates, logging, termination. Examples: open-source and commercial harnesses (e.g. pi.dev) — named nominatively, no endorsement.
- Governance layer
- Policy, evidence, and oversight applied to the harness: what it may call, who approves what, what is recorded, how changes are controlled.
- System provider vs. platform provider
- IMDA's updated framework distinguishes roles across the agent value chain; the deploying organisation remains accountable for the system it runs.
Bitstric works on the governance layer over third-party harnesses — we are not a harness vendor, and nothing on this page should be read as a compatibility or endorsement claim.
How supervisory expectations land on the stack: the model produces tokens; the harness turns them into bounded action; governance is applied to the harness, not the model.
The regulatory landscape
Each instrument below carries a different legal weight — guideline, principle, or statute — and a different degree of relevance to the harness specifically.
| Instrument | Issuer | Date | Status | Nature | Harness relevance |
|---|---|---|---|---|---|
| Consultation Paper — Guidelines on AI Risk Management | MAS | 13 Nov 2025; comments closed 31 Jan 2026 | Final text pending — 12-month transition proposed after issuance | Supervisory expectations (guidelines, not statute) | High |
| Model AI Governance Framework for Agentic AI | IMDA | Launched 22 Jan 2026; updated 20 May 2026 | Issued (voluntary framework) | Guidance | Very high |
| FEAT Principles | MAS | 2018 | In force (principles) | Principles | Medium |
| Technology Risk Management Guidelines | MAS | Current edition — reverify on publish | In force | Supervisory expectations | Medium |
| Personal Data Protection Act | PDPC | — | In force | Statute | Medium |
This page summarises public documents for analysis. It is not legal advice.
The harness control map
Supervisory expectations are written in outcome language — “bound the autonomy,” “ensure human oversight,” “maintain auditability.” In an agentic system, each of those outcomes resolves to a specific harness mechanism. The map below pairs them, and names the artefact an examiner or internal auditor would reasonably ask to see.
| Harness component | MAS AIRG expectation area (proposed) | IMDA MGF Agentic dimension | Evidence artefact to produce |
|---|---|---|---|
| Tool registry & permissions (allowlist, scopes) | Technology & cybersecurity; third-party AI risk | Assess & bound risks (limit tools/data access) | Versioned tool manifest per agent; access review record |
| Agent identity & credentials | Technology & cybersecurity | Technical controls (access control) | Agent-scoped service identities (not borrowed human creds); credential rotation log |
| Human approval gates | Human oversight | Meaningful human accountability (checkpoints) | Gate policy by action class; approval/override log incl. override rates |
| Trace / action logging | Reproducibility & auditability; post-deployment monitoring | Technical controls (logging & monitoring) | Replayable trace: prompt → plan → tool call → result → decision |
| Runtime guardrails / policy enforcement | Transparency; data management | Technical controls (guardrails) | Policy set with version; block/allow events |
| Memory / context store | Data management; PDPA | Bound risks (data access) | Data classification of context sources; retention rule |
| Evaluation harness (pre- and post-deploy) | Evaluation & testing; pre-deployment review | Technical controls (baseline testing) | Test suite on harness + tools, not model alone; repeat-run results |
| Config & prompt versioning | Change management | Technical controls (lifecycle) | Change record per harness/config release |
| Kill switch / override | Incident management (override mechanisms for high-materiality AI) | Human accountability | Tested deactivation procedure; last test date |
| Third-party harness / agent | Third-party AI risk management | Multi-agent & third-party agents (May 2026 update) | Vendor assessment; supplier assurance; exit plan |
| Decommissioning | Decommissioning | Lifecycle | Retirement record; credential revocation evidence |
“How to read this”: the mapping above is Bitstric's interpretation; column headings paraphrase the source documents. Readers should consult the originals in §4.11 before relying on this mapping.
Five recurring gaps in agent deployments
Patterns observed across public frameworks and industry commentary — not a client engagement record.
Agents run on a human user's credentials
Why it matters: Breaks attribution; access reviews can't see agent actions
What good looks like: Agent-scoped identity with least privilege
Logs capture prompts, not actions
Why it matters: Auditability expectation is about what the system did
What good looks like: Action-level, replayable trace
Evaluation stops at the model
Why it matters: Harness + tools change behaviour more than model swaps
What good looks like: Evaluate the full agent loop, repeat-run, not single-shot
Harness config changes outside change control
Why it matters: Silent behaviour drift
What good looks like: Harness config treated as a governed release
Third-party harness never assessed as a vendor
Why it matters: Accountability stays with the FI
What good looks like: Harness in third-party AI inventory with supplier assurance
Proportionality — tiering agent use cases
MAS's consultation sets out proportionate application in its Annex; the tiers below are illustrative, not MAS's taxonomy.
Internal document Q&A, read-only
Autonomy / access: No write tools; internal data
Expected controls: Logging, periodic review
Drafting customer comms for human send
Autonomy / access: Read + draft; human sends
Expected controls: Approval gate on send; output review sampling
Agent executing account actions / payments
Autonomy / access: Write tools on customer-affecting systems
Expected controls: Pre-deployment review, per-action approval or tight bounds, kill switch tested, full trace, incident runbook
What to watch
- Final MAS AIRG text and effective date → starts the proposed 12-month transition.
- How “AI agent” scope and risk materiality will be defined in the final text.
- Supplier-side assurance for third-party models/harnesses (raised in industry consultation responses).
- IMDA MGF Agentic case-study additions and multi-agent guidance evolution.
Twelve items, no email required
- 1Inventory every agent in production/pilot, including vendor-embedded agents.
- 2Record which harness each runs on (in-house / OSS / vendor).
- 3Assign a risk-materiality tier per agent.
- 4Give each agent its own identity; remove shared human credentials.
- 5Define approval gates by action class.
- 6Confirm action-level, replayable logging.
- 7Put harness config under change control.
- 8Test the kill switch; record the date.
- 9Evaluate the full agent loop, repeat-run.
- 10Add third-party harnesses/agents to vendor risk.
- 11Classify data reachable via agent memory/context (PDPA).
- 12Name an accountable owner per agent.
Frequently asked questions
Primary sources
- 1.MAS — Consultation Paper on Guidelines on Artificial Intelligence Risk Management (13 Nov 2025)
- 2.IMDA / MDDI — Model AI Governance Framework for Agentic AI (22 Jan 2026)
- 3.IMDA — Model AI Governance Framework for Agentic AI (updated) (20 May 2026)
- 4.MAS — FEAT Principles (2018)
- 5.MAS — Technology Risk Management Guidelines (current edition) (Reverify on publish)
- 6.PDPC — PDPA overview (—)optional
Method: this mapping was built by reading each instrument's stated expectation areas and pairing them against the harness components they most directly constrain. It is interpretive, not a reproduction of source text. Last reviewed 28 Sep 2026.
Bitstric builds governance and audit tooling for AI agent deployments in regulated environments. We wrote this analysis because this is the problem we work on; it is not a product comparison.
Governance layer over third-party harnesses; sovereignty-first deployment options.