01 Purpose and scope
This framework describes how Tangent9 governs the design, deployment, and operation of the AI features in our products, including the AI Personal Assistant (PA) Platform and the Agentic Workforce Platform. It explains the controls built into our AI orchestration layer and how those controls are designed to meet the expectations of Singapore's AI governance guidance.
It applies to all AI features powered by large language models (LLMs) across our products, and to everyone who builds, configures, operates, or relies on those features. It complements, and should be read alongside, our Privacy Policy and Terms of Service.
Singapore's AI governance frameworks are voluntary and principles-based: they describe what good governance looks like rather than prescribing a fixed checklist. Where this document says we "align with" or are "designed to meet" a framework, we mean that our architecture and processes are built around its principles. We do not represent that any deployment is certified or audited against a framework unless stated separately in writing.
02 Guiding principles
Our approach rests on the two principles at the heart of the IMDA Model AI Governance Framework, and on a third that reflects how our products are built:
- Human-centric. AI assists people; it does not replace their judgement. Decisions that affect individuals remain with a human.
- Explainable, transparent, and fair. We are open about where AI is used, treat AI outputs as drafts rather than verified records, and design for traceability so decisions can be reviewed.
- Architecture-first safety. Governance is enforced in the system, not left to good intentions. The controls described below are built into the orchestration layer that sits between users and the underlying models.
03 Frameworks we align to
Tangent9 designs its AI governance around Singapore's AI governance instruments, published by the Infocomm Media Development Authority (IMDA), the Personal Data Protection Commission (PDPC), and the AI Verify Foundation. Because our products use generative and agentic AI, all three editions of the Model AI Governance Framework are relevant.
Model AI Governance Framework
The foundational framework. Four governance areas covering internal governance, human involvement in decisions, operations, and stakeholder communication.
ReferenceModel AI Governance Framework for Generative AI
Extends the framework to generative AI through nine dimensions, from accountability and data to testing, security, and content provenance.
ReferenceModel AI Governance Framework for Agentic AI
The first framework built for autonomous AI agents. Four dimensions: bounding risk upfront, meaningful human accountability, technical controls, and end-user responsibility.
ReferenceWe also operate in accordance with the Singapore Personal Data Protection Act 2012 (PDPA), as set out in our Privacy Policy.
04 The Tangent9 AI orchestration layer
Every AI action in our products passes through an orchestration layer: a governed pathway that sits between the user (or an agent) and the third-party LLMs that provide reasoning. The model never acts directly on your systems. Instead, the orchestration layer screens the request, decides what level of human involvement is required, calls the model with the minimum data needed, validates the result, and executes only authorised actions through a trusted backend. Every step is logged.
1. Input safety and PII masking Pre-model
Incoming requests are screened for unsafe content and for prompt-injection, jailbreak, and identity-spoofing attempts. Personal data detected in inputs, such as NRIC numbers, payment card numbers, or API keys, is designed to be masked before anything is forwarded to an LLM provider.
2. Identity and access control Trusted backend
Access is granted by backend permission mechanisms on a least-privilege basis. A user-claimed identity or role is never accepted as a basis for elevated access. Agents receive only the connectors and tools their function requires, and connector credentials are held in the trusted backend, not exposed to the AI layer.
3. Risk-tiered action classification Decision gate
Each proposed action is classified by risk tier (Low, Medium, High, or Critical). The tier determines how much human involvement is required before the action can proceed, and routes consequential actions into an approval workflow.
4. Human approval gate Human in the loop
Any action that sends external communications, modifies or deletes records, moves money, or changes permissions is held for explicit human approval. Completing an earlier step never counts as approval for a later one, so a workflow cannot quietly authorise itself.
5. Model reasoning Anthropic · OpenAI
The orchestration layer calls the configured LLM provider with only the masked, minimum data required for the task. Outputs are treated as drafts and recommendations, never as verified facts or final decisions.
6. Output validation Post-model
Model outputs are validated before they are surfaced or acted on. Extractions such as scanned contacts or receipts are flagged for the user to verify, and outputs are presented as draft material requiring review.
7. Authorised execution Trusted backend
Only approved actions are executed, and only through the trusted backend that holds connector credentials. The AI layer requests an action; the backend decides whether it is permitted and carries it out.
Audit logging spans every stage
Inputs, outputs, classified actions, tool and connector calls, and approval events are recorded in an audit log for security, debugging, governance, and incident response. Sensitive fields are masked in the logs. This is what makes the layer traceable and reviewable after the fact.
05 Risk-tiered actions and human oversight
The orchestration layer scales human involvement to the consequence of the action, in line with the IMDA Model Framework's idea of choosing the right level of human involvement based on the probability and severity of harm. The four tiers map to familiar oversight models: the human stays in, over, or out of the loop depending on risk.
- Low
- Routine, low-impact, and reversible actions (such as retrieving or summarising information) can proceed automatically. The human is "over the loop": free to review, with everything logged.
- Medium
- Actions with moderate impact require the user's explicit confirmation before they execute. The human is in the loop at the point of action.
- High
- Consequential actions (external communications, record changes, financial steps) require human approval through the workflow engine before execution.
- Critical
- The highest-impact actions (such as permission changes or deletions) require human approval and are subject to additional review. These controls cannot be configured away without the customer accepting responsibility for doing so.
For the Agentic Workforce Platform, the same principle governs unattended (scheduled) agents and multi-agent handoffs: consequential steps must pass through a human approval checkpoint, and customers are expected to review unattended agent output on a regular basis.
06 Mapping to the Agentic AI framework
Because our Agentic Workforce Platform deploys autonomous and semi-autonomous agents, the IMDA Model AI Governance Framework for Agentic AI (January 2026) is the most directly relevant. Its four dimensions map to the orchestration layer as follows.
- Assessing and bounding risk upfrontIn the platform
- Agents are scoped to specific use cases and granted only the connectors, tools, and data their function requires. Least-privilege configuration and risk-tiered action classification place explicit limits on an agent's autonomy and reach before it runs.
- Making humans meaningfully accountableIn the platform
- Significant checkpoints require human approval before consequential actions execute. Earlier steps never imply later authorisation, approval events are logged against a named approver, and a human remains accountable for every decision the agent supports.
- Implementing technical controls and processesIn the platform
- Backend permission mechanisms, credential isolation, input safety screening, output validation, and comprehensive audit logging are enforced by the system rather than left to configuration discipline.
- Enabling end-user responsibilityShared with the customer
- We provide the controls, documentation, and default safeguards; deploying organisations are responsible for configuring agents safely, authorising connectors through their own governance, and training their users. These responsibilities are set out in our Terms of Service.
07 Mapping to the Model AI Governance Framework
The foundational Model AI Governance Framework (2nd edition, 2020) organises good practice into four governance areas. Our framework addresses each.
- Internal governance structures and measuresOperational
- Defined ownership for AI governance, a documented risk approach, audit logging for monitoring, and a regular review cycle (see Section 9).
- Human involvement in AI-augmented decisionsIn the platform
- The risk-tiered model in Section 5 sets the level of human involvement by the probability and severity of harm, keeping a human in or over the loop for anything consequential.
- Operations managementIn the platform
- Data minimisation and purpose limitation, working from authoritative sources, PII masking, output validation, and end-to-end audit logging support data quality, traceability, and auditability.
- Stakeholder interaction and communicationOperational
- We disclose where AI is used, label AI-generated content as draft material to verify, publish this framework and our policies, and provide channels to raise questions and incidents.
08 Mapping to the Generative AI framework
The Model AI Governance Framework for Generative AI (2024) sets out nine dimensions to be considered together. Some are enforced directly in our platform; others are shared with the LLM providers whose models we use, or sit on our roadmap. We aim to be candid about which is which.
- AccountabilityOperational
- Named governance ownership, audit trails, and accountability obligations under the PDPA, with responsibilities allocated between us and our customers.
- DataIn the platform
- Data minimisation, purpose limitation, scoped access, and PII masking before data reaches a provider.
- Trusted development and deploymentIn the platform
- A layered safety architecture with input controls, output validation, approval gating, and disclosure through our published policies.
- Incident reportingOperational
- An incident-response process (Privacy Policy, Section 17) and a dedicated channel for customers to report agent safety incidents to us.
- Testing and assuranceDeveloping
- We evaluate features before release and monitor for behavioural change after provider model updates. Independent assurance, for example through AI Verify, is part of our roadmap rather than a current claim.
- SecurityIn the platform
- Role-based access control, credential isolation from the AI layer, input screening, log masking, and encryption in transit and at rest where appropriate.
- Content provenanceShared with providers
- We label AI-generated and AI-extracted content so users know its origin and verify it. Cryptographic provenance and watermarking of model output largely depend on the LLM providers.
- Safety and alignment R&DShared with providers
- Underlying model alignment is the providers' domain; we add orchestration-level guardrails, monitor for material behavioural change across model versions, and can switch or constrain providers.
- AI for public goodBy design
- Our mission is to make enterprise-grade AI accessible to smaller organisations, with human oversight built in so adoption stays responsible.
09 Governance, accountability and review
AI governance is treated as a continuous responsibility, not a one-off exercise.
- Ownership. A named owner is accountable for this framework and for the controls in the orchestration layer.
- Monitoring. Audit logs and operational monitoring are used to detect anomalies and to investigate incidents.
- Provider change management. We monitor for material behavioural changes when LLM providers update their models, and take action where needed, while recognising we cannot guarantee identical behaviour across versions.
- Review. This framework is reviewed at least annually, when a new product capability, integration, or processing purpose is introduced, when applicable guidance materially changes, and after any High or Critical incident.
10 Limitations and shared responsibility
We are deliberate about what these controls can and cannot promise.
- No AI system is perfect. AI outputs are probabilistic and may be incomplete, inconsistent, or incorrect. Our controls reduce risk; they do not eliminate it, and we do not warrant that every unsafe input will be caught or every output will be accurate.
- Controls are design obligations. Measures such as PII masking and bounded agent access are designed safeguards whose effectiveness depends on correct configuration and authorised use, not absolute guarantees.
- Configuration is shared responsibility. Where a customer reduces or removes oversight controls, or grants agents broad access against our guidance, the customer accepts responsibility for the resulting risk, as set out in our Terms of Service.
The orchestration layer is built so that AI supports human decisions and consequential actions require a human. Keeping that oversight in place is how the framework stays effective.
11 Related policies
This framework sits alongside the rest of our trust documentation:
- Privacy Policy, how we collect, use, and protect personal data, including AI inputs and audit logs.
- Terms of Service, the terms governing use of our products, including the AI Features notices and customer responsibilities.
- Resource centre, all of our policies, technical overviews, and support in one place.
12 Contact
For questions about this framework or our AI governance practices, contact us: