Model governance
SYSTEM ASSURANCE- 01Model
- 02Evaluation
- 03Documentation
- 04Monitoring
Asks whether the AI system is appropriately designed, tested, documented and monitored.
Aivance point of view · Agentic AI governance
Govern AI at the point of action
As AI agents gain the ability to use tools, access enterprise systems and act autonomously, governance can no longer depend only on understanding the model. Organisations need enforceable controls over what agents are permitted to do.
What is this agent allowed to do, under what conditions, based on what evidence?
The question behind the objection
Already have guardrails?
System prompts, agent instructions and content filters can guide behaviour and reduce risk. They do not independently prove that a proposed tool call is within authority, verify its claims against current system evidence, or hold an enterprise write before it takes effect.
Prompts are not governance. The agent should not be the sole authority on whether its own action complies with policy. Consequential actions need explicit, independently testable conditions and a decision at the execution boundary.
Read: Prompts Are Not Governance →See the difference: in the scripted policy-only scenario, the agent trusts its own approved claim while verified risk-system status is pending; the simulated system accepts the write.
The governance surface is changing
From model governance to action governance
Model risk, evaluation, fairness, explainability, documentation, monitoring and human oversight remain important. Agentic systems add a second question: should this specific action be allowed at this moment?
Runtime governance
ACTION CONTROL- 01Agent
- 02Proposed action
- 03Runtime decision
- 04System effect
- 05Decision lineage
Asks whether a particular action is authorised under the conditions and evidence available now.
Model governance and runtime governance are complementary. One governs how an AI system is built and assessed; the other governs the actions it may take in operation.
A control point in the execution path
Put a governance boundary between the agent and the action
A runtime governance layer evaluates a proposed action before execution. It can test whether the agent has the required authority, policy conditions are satisfied, evidence is sufficient and human approval is needed. Place the control as close as practical to the point where the agent produces an external effect.
01 / ACTOR AI agent with a defined identity
02 / INTENT Proposed action tool call · transaction · change
03 / CONTROL POINT
Before external effect Runtime governance boundary
- 01 IdentityWho is acting?
- 02 AuthorityWhat may they do?
- 03 ContextWhat conditions apply?
- 04 EvidenceWhat can be verified?
- 05 PolicyWhich rules govern?
- 06 ImpactWhat is at stake?
Allow Deny Escalate
04 / EXECUTION Enterprise system tool · API · application
05 / ACCOUNTABILITYExecution evidenceDecision lineage links the proposed action, evidence, policy, decision and outcome.
The boundary is a governance design pattern, not a claim that every action can be intercepted in every architecture. The appropriate enforcement point depends on how the agent, tools and enterprise systems are connected.
Aivance calls the limit of an agent’s autonomous operation the Agentic Risk Boundary: the conditions beyond which it needs human ratification.
Interactive demonstration
The request stays the same. The control path changes.
Choose a control path and run this fictional credit-limit request. Compare what happens with enforcement against a policy-only path. This scripted example has no connected agent, customer data or enterprise system.
SAMPLE REQUEST · DEMO-4812
Fictional scenario Increase the customer’s credit limit from S$10,000 to S$25,000.
Agent-provided approval: approved Verified risk-system status: pending
Pre-action checks
- 01 IdentityNot checked
Who is acting?
- 02 AuthorityNot checked
What may they do?
- 03 ContextNot checked
What conditions apply?
- 04 EvidenceNot checked
What can be verified?
- 05 PolicyNot checked
Which rules govern?
- 06 ImpactNot checked
What is at stake?
Click “Evaluate identity” below to start the enforced path.
ENFORCED AT THE EXECUTION BOUNDARY
Verified identity, authority, evidence and policy are checked before the proposed write can reach the customer system.
POLICY GUIDANCE ONLY
The scripted agent follows its task instructions and trusts its own approved field. No independent control checks the risk system before the write.
LATEST CHECK EVIDENCE
Waiting for the first check
Evaluate a check to see what the boundary verifies before the action can proceed.
PRE-ACTION DECISION RECORD 0 / 6 checks
Decision record builds as checks complete.
Escalate · hold before execution
A human risk approver must decide.
The authority limit and pending approval prevent the agent from changing the credit limit. The action waits for an identified approver.
Submitted · simulated system accepts
The claimed approval is taken at face value.
In this scripted failure mode, the agent submits the change and the simulated system applies it. Real systems vary; this illustrates what can happen when no control verifies the claim before execution.
SAME EVENT · DIFFERENT RECORD
Activity log
- Time
- 14:32:08 SGT · simulated
- Agent
- credit-assist-07
- Action
- Increase limit to S$25,000
- Outcome
- Held before execution
Pre-action decision record
- Authority
- Recommendation only; write is outside delegated scope
- Verified evidence
- Risk approval status: pending
- Policy
- Credit Change Policy v3.2
- Decision
- Escalate; require named human approval
- Execution
- Held; no account change made
No pre-action decision record
The policy-only path made no independent authorization decision to preserve. Its activity log records the update after the simulated system accepted it.
Illustrative scenario only. The scripted outcomes are not a prediction about every agent or a claim about a deployed Aivance product.
Apply this to your architecture
Where would this action be stopped in your system?
Trace one consequential AI action through your current controls in a complimentary 30-minute Enforcement Gap Review. We identify where policy still depends on the agent or human follow-through.
The agent harness
The harness shapes what an agent can do
An agent harness brings together the model, prompts, tools and orchestration that let an agent carry out a task. In production, its runtime environment also shapes identity, data context, memory, retries, observability and how changes are made. Those engineering choices affect which systems an agent can reach and what evidence exists when it acts.
Governance needs a voice in harness design, especially at the boundaries where tools and APIs create real effects. A well-designed harness can provide practical control points, but it does not replace policy enforcement, independent evidence or decision lineage.
Why production governance goes beyond the harness →Evidence-backed runtime governance
A policy decision is only as trustworthy as the evidence behind it
A deterministic policy can still reach the wrong result if it relies on unverified context supplied by the agent whose action it is evaluating.
What the agent supplies
- Claimed purpose
- Claimed data classification
- Task description
- Self-reported risk
- Semantic labels
agent says: data_classification = "public"
What the organisation can verify
- Agent and user identity
- IAM permissions
- System-of-record classification
- Transaction limits
- Tool metadata and approval state
verified source: data catalogue · record 8421
01Agent assertion
02Evidence verification
03Policy decision
04Authorization
05Execution evidence
Distinguish what the agent claims from what the organisation can independently verify.
A practical decision model
Every consequential agent action should answer six questions
- 01 / DECISION CHECK
Who is acting?
Which agent, user, service or delegated identity is responsible?
- 02 / DECISION CHECK
What is being attempted?
What tool call, transaction, data access or external action is proposed?
- 03 / DECISION CHECK
What authority exists?
Is this identity permitted to perform this type of action?
- 04 / DECISION CHECK
What evidence supports it?
Which attributes are independently verified, and which are asserted?
- 05 / DECISION CHECK
What policy applies?
Are limits, data rules and approval conditions satisfied?
- 06 / DECISION CHECK
What happened?
What decision was made, what executed and what evidence was retained?
When a check requires escalation, the system can enter a Suspended Handoff State and wait at a Human Ratification Gate for an identified person to approve or reject the action.
AllowDenyEscalate
Evidence after the decision
Create decision lineage at the moment of decision
Governance should capture more than logs after the fact. Decision lineage links the attempted action to the evidence and policy available at that moment, the decision, any human approval and the eventual outcome.
That trace can support audit, assurance, incident investigation, compliance evidence, control testing, accountability and continuous improvement. It does not by itself establish regulatory compliance.
A useful governance record connects
- 01Agent and requesting identity
- 02Requested action and context
- 03Verified evidence and its source
- 04Policy and version evaluated
- 05Decision and required approval
- 06Executed action, response and timestamp
Enterprise applications
Where runtime governance matters
The control questions become concrete wherever an agent can create an operational consequence.
Financial transactions
Before an agent initiates a payment, evaluate its identity, delegated authority, amount, beneficiary and approval threshold.
Customer data
Before data reaches an external service, verify classification, destination, purpose and the applicable disclosure policy.
Privileged changes
Before an agent creates an account or changes configuration, check privilege boundaries and require approval where the impact warrants it.
Customer commitments
Before an agent sends a binding offer or contractual communication, confirm that the commitment falls within its delegated authority.
Agent delegation
When one agent hands work to another, keep the resulting authority within the limits granted to the originating identity. Individually tested agents can still create untested system behaviour when they coordinate.
Aivance approach
How Aivance helps
Aivance helps organisations move from governance intent to implementation-ready control architecture. The work is designed around your systems and can involve appropriate enterprise technologies; Aivance does not position itself as a proprietary enforcement platform.
- 01 DISCOVER
Discover
Map agents, tools, data, identities, owners and the actions they can initiate.
- 02 CLASSIFY
Classify
Assess action impact, authority, risk and applicable obligations.
- 03 AUTHORIZE
Authorize
Define permitted actions, boundaries and approval conditions.
- 04 ENFORCE
Enforce
Specify runtime controls that implement policy at the point of action.
- 05 EVIDENCE
Evidence
Preserve decision lineage, approvals and execution records.
A joined-up control environment
Governance, security and assurance need to work together
Runtime governance intersects with cybersecurity, IAM, PAM, API security, data governance, model governance, AI assurance and observability. Each has a distinct role.
IAM and PAM establish who an identity is and the permissions it can generally exercise. API security protects and constrains the interface. A runtime governance decision asks a narrower question: may this identity perform this specific action now, given its purpose, amount, current evidence, policy conditions and potential impact?
The existing stack supplies identity, permissions and enforcement mechanisms. The governance layer supplies the action-specific decision and its lineage. Aivance helps organisations design how those capabilities work together.
Production friction
Does every check slow the agent down?
It can, if every action is routed through the same heavy review. Good control architecture does not treat every action as equally consequential. Low-risk actions can use fast, deterministic checks against cached identity, authority and policy data. Higher-risk, ambiguous or irreversible actions can be denied or held for human ratification.
Runtime enforcement is not inherently slow. Kyvvu, for example, reports a p99 evaluation time of 0.296 ms for 100 policies against a 50-step history in its local, in-process engine. This is a vendor-published benchmark of policy evaluation rather than end-to-end action latency, but it shows that pre-action checks can be engineered with very low computational overhead.
The right design defines which actions need interception, what evidence must be fresh, which decisions can be evaluated locally, and where human approval is worth the delay. Latency budgets and failure behaviour should be specified and tested for each action class; there is no universal performance figure that applies to every architecture.
Why this matters now
Less visibility. More consequence.
As agents gain broader tool access and carry out longer chains of action, organisations can face greater operational consequences while getting less dependable visibility into internal reasoning. In his 6 September 2026 essay “An Alien Mind,” OpenAI Chief Scientist Jakub Pachocki writes that the ability to rely on chain-of-thought monitoring is progressively diminishing while work to improve monitorability continues. He also calls for defensive systems that protect infrastructure against rogue agents in real time.
The essay describes OpenAI’s research and priorities; it does not assess or endorse Aivance. Our architectural inference is that visibility remains valuable, while consequential actions also need independently enforced permissions and retained decision evidence where the architecture permits.
Preparing to deploy AI agents into production?
Aivance helps organisations identify where agent actions create enterprise risk and design enforceable governance controls around identity, authority, policy, trusted evidence and accountability.
Discuss your agentic AI governance architecture