Enforcement · Planned · Hybrid and sovereign-connected
Enforcement is the layer of AI Pulse that can stop an agent, not merely record it — inline guardrails, tool-intent checks before the agent acts, and an Action Gatekeeper that pauses a sensitive action for human approval. Deploy it and the same portal runs wherever your agents do, including sovereign, air-gapped and self-hosted estates.
01Why now
MAS's draft Guidelines on Artificial Intelligence Risk Management do something most regulation has not: they name autonomous AI agents explicitly, alongside generative AI, as systems financial institutions must govern. Once final — expected in 2026, with a proposed 12-month transition — MAS will assess firms' AI risk management at inspections and supervisory reviews.
Agents are different from models. A model answers; an agent acts — it calls tools, moves data, triggers transactions. Observing a model's outputs is no longer enough when the system in production can do things on its own authority. Governance for agents has to be able to stop an action, not just record it.
Source: MAS, Consultation Paper on Guidelines on Artificial Intelligence Risk Management, 13 November 2025. Consultation closed 31 January 2026; guidelines expected in 2026, with a proposed 12-month transition period. Consulted on — not yet in force.
“Autonomous AI agents”
Named expressly in the MAS draft guidelines — in scope for all financial institutions, alongside generative AI. Consulted on; expected 2026; not yet in force.
Source: MAS, Consultation Paper on Guidelines on Artificial Intelligence Risk Management, 13 November 2025. Consultation closed 31 January 2026; guidelines expected in 2026, with a proposed 12-month transition period. Consulted on — not yet in force.
02The model
Every agent sits on two orthogonal ladders, and you set each independently — per agent and, for control, per action class.
Visibility is how deeply you see. Tier 1 is automatic for every registered agent: the gateway records every prompt, response, token and exact cost, because an unregistered agent cannot reach a model at all. Tier 2 adds framework-native traces — tool results, retrieved sources, sub-agent structure — with a configuration change, no code. Tier 3 adds business context through a thin SDK, for the few agents that justify a real code change.
Control is how much the platform can stop. C0 observes and scores. C1 runs deterministic guardrails inline — personal data, secrets, jailbreak signatures — fast enough to block the call itself. C2 inspects the action an agent intends to take before the agent ever sees it: block it, redact it, or hold it for approval — and every new rule runs in shadow first, so nothing blocks live traffic unreviewed. C3 is the Action Gatekeeper, inline on the action path itself.
The axes are genuinely independent: an agent can run at Tier 1 visibility with C3 control — you see little of its reasoning, yet it cannot move money without approval — or Tier 3 with C0. And the floor is never zero: every agent on your network is registered and recorded from day one. Vendor-hosted SaaS agents that never touch your network get the honest, separate answer — connector visibility from the vendor's own audit logs, labelled as exactly that, never oversold.
03Enforcement
Actions are checked against the policies you write — recipients, amounts, tools, rolling velocity ceilings — before they execute. At C2 the intended action is inspected before the agent even sees it; at C3 the Gatekeeper permits, denies or pauses it for maker-checker approval.
Every proposal, check, approval and stop is written to an append-only, tamper-evident ledger. When a supervisor asks what your agents did and why they were allowed to, the answer is a record, not a reconstruction.
The Gatekeeper never holds or uses a credential and never executes anything. Agents act with their own scoped credentials, issued by you; approval is bound to the exact parameters approved. A vendor that cannot use what it does not hold cannot become your breach.
Enforcement is exactly as strong as you set it, per agent, and never stronger. It is the deliberate counterpart to the read-only posture: there, nothing can write; here, only what you authorised. The two never blur.
04In the path
Enforcement is not a policy document. These are the components an agent's traffic physically passes through, and what each one refuses.
Each agent declares the tools it may call. A call to anything else is refused at the gateway and the verdict is recorded — including the case where an agent has declared no allowlist at all, which is itself a finding rather than a free pass. New rules run in shadow first, logging what they would have refused against real traffic, so nothing starts blocking on the day it is written.
Every MCP call runs through an in-path broker: it authenticates the agent, checks the live server against a human-approved baseline, scans the arguments for personal data, records the decision, and only then forwards it. Capability discovery is answered from the approved baseline — so a server that quietly rewrites a tool description cannot put that unapproved text into the model's context. It fails closed: no identity, no policy, no attestation, no call.
A paused action resumes only against an approval bound to the exact recipient and amount that a human approved — change either and it is refused. Approvals are single-use, they expire, and recording one requires a separate operator credential, so an agent cannot approve its own paused action. Reading the approval queue is a different credential again.
Every decision is sealed into a hash chain — each entry hashed together with the one before it. Change a field and its hash stops recomputing; delete or reorder a row and the next entry's link breaks; trim the start and the run no longer begins at genesis. The chain is verified by a separate auditor-facing checker, not by the service that wrote it.
Two honest limits, because they matter to anyone evaluating this: only agents routed through the broker are governed by it, and an MCP server running inside an agent's own process cannot be brokered remotely at all.
05Anywhere your agents run
With enforcement deployed, AI Pulse is cloud-agnostic: it runs on any cloud and with self-hosted estates, because agents live everywhere and governance has to live with them. A consequence of that architecture — not a separate product — is that it also runs in sovereign clouds and fully air-gapped environments, with no dependency on outside connectivity.
For government, defence-adjacent and critical-infrastructure estates, that means governance can sit inside the same boundary as the workload. Evidence stays where the agents are.
It is also the answer to vendor risk: everything is self-hosted inside your boundary, so prompts and completions never reach SYLVA Labs. There is no vendor-side copy of your data to breach.
06From finding to fix
A Gatekeeper denial, repeated intent blocks, drift past a threshold, a fail-open event — findings like these should not stop at a chart. The Incident & Remediation Bridge routes each one to where action actually happens.
Self-heal is reserved for a short, pre-approved list of reversible actions. Everything else lands where your teams already work: a ticket in ServiceNow or Jira Service Management, and an event in your SIEM — Splunk natively over HTTP Event Collector; Microsoft Sentinel and any other collector by polling a token-secured export endpoint or receiving an HMAC-signed HTTPS push.
And the Bridge is given no permanent licence to act. Beyond that pre-approved self-heal list it can only raise, route and notify — a human always makes the call.
07What's inside
The plumbing is proven open source under free MIT and Apache-2.0 licences — the AI gateway, the trace store, the safety scanner, the telemetry collector. Referenced from the upstream registries and pulled by your own infrastructure: never embedded, never forked, never redistributed by us, and no paid tier of any of them is used.
The governing is SYLVA's own build: the Policy Engine, the Action Gatekeeper, the Incident & Remediation Bridge, and the AI Pulse application itself. Your architecture review board gets the component-by-component justification — every container, its licence, the data it touches and its blast radius — during evaluation.
