AI GOVERNANCE PROTOCOL

Embedding Accountability at Every Stage of the AI Solution Development Lifecycle

A Defense-in-Depth Framework Against Prompt Injection, Promptware, and Agentic Drift

Prepared by Dr. Suresh Kumar Krishnan

Strasys Solutions Sdn Bhd, Kuala Lumpur

July 2026

 

0. Framing Note: Reject "Unbreakable," Design for "Resilient and Accountable"

No AI system — agentic, generative, or otherwise — can be made unbreakable. Every control in this protocol reduces the probability and blast radius of failure; none eliminates it. This is not a caveat to soften the promise, it is the design principle itself: a governance architecture that assumes controls will occasionally fail, and therefore never relies on a single control to carry the whole risk. This mirrors the argument already embedded in Enterprise AI Agent Blueprint — an agentic system without equal weight of governance is "a fast car with no brakes." What follows extends that principle across the full solution lifecycle, not just the execution layer.

Working definition used throughout: "Governance" here means the set of enforceable checkpoints, ownership assignments, and audit trails that make an AI system's behavior predictable, traceable, and stoppable — not a policy document that exists separately from engineering.

1. Why Governance Can No Longer Be a Late-Stage Checklist: The Promptware Problem

Traditional application security assumes a clean separation between "code" (trusted, fixed at deploy time) and "data" (untrusted, arrives at runtime). Large language model systems collapse that separation: instructions and data travel through the same channel, in natural language, and the model cannot reliably tell which is which. This is the structural reason prompt injection behaves like malware rather than a normal input-validation bug — and why security researchers increasingly describe it using kill-chain language borrowed from traditional cyber-defence:

•   Delivery — untrusted content (a document, email, web page, tool result, or another agent's output) enters the model's context window.

•   Execution — the model treats embedded instructions in that content as if they were legitimate commands from the operator or user.

•   Propagation — if the agent has tool access (file systems, APIs, email, code execution, other agents), the injected instruction can act in the real world, not just in a chat reply.

•   Persistence / Impact — the action alters memory, state, downstream systems, or data in ways that outlast the single conversation turn and may be difficult to trace back to its origin.

The governance implication is direct: because the vulnerability is structural (shared instruction/data channel) rather than a single patchable flaw, no amount of governance concentrated only at the "deployment" stage can close it. Control must be distributed across every discipline in your Foundation → Execution → Governance stack, so that a failure at one layer is caught by an independent control at the next.

 

2. Lifecycle-Embedded Governance Protocol

The table below takes the seven-stage AI Solution lifecycle (Data → ML Approach → Model/Agent Selection → Evaluation & Refinement → Deployment & Integration → AI System Feedback & Governance → Continuous Improvement) and attaches a mandatory governance gate to each stage. No stage should be considered "complete" until its gate question can be answered in the affirmative with evidence, not assurance.

Lifecycle Stage	Governance Gate Question	Required Controls	Primary Owner
1. Data Ingestion & Types	Is every data source classified, consented, and provenance-tagged before it touches the model?	Data classification tiers; PDPA 2010 consent basis logged; lineage tagging; bias/leakage screening	Data Engineering Lead
2. ML Approach Selection	Does the chosen learning paradigm (supervised/unsupervised/transfer/RL) match a documented business justification, not just technical convenience?	Model-choice memo with risk tier; compute/budget sign-off; fairness-by-design review	AI/ML Lead (CTO)
3. Model & Agent Selection	If this is an agent (not just a model), has its tool radius, memory scope, and autonomy level been explicitly bounded?	Least-privilege tool grants; memory scope limits; explicit "agent job description" (Prompt/Agent Design Engineering)	Solution Architect
4. Evaluation & Refinement	Has the system been red-teamed for prompt injection and jailbreak resistance, not just accuracy-tested?	Adversarial test suite; robustness metrics; human evaluation of edge cases; documented pass/fail thresholds	AI Safety/QA Lead
5. Deployment & Integration	Is there a human checkpoint before any irreversible or high-value action, and is every tool call logged?	API gateway with rate/scope limits; human-in-the-loop gates for high-risk actions; full trace logging	Head of Engineering (COO/CPO sign-off for external-facing systems)
6. AI System Feedback & Governance (AIG)	Can every model decision be traced back to a version, a data lineage, and a responsible owner?	Model versioning/lineage; RLHF and AMLF feedback loops; audit-ready documentation; transparency dashboards	AI Governance Lead / DPO
7. Continuous Improvement	Are metric reviews and incident learnings institutionalized, or dependent on one person remembering?	Scheduled data/model/deployment metric reviews; incident playbooks; closed-loop sprint cadence	Cross-functional Governance Committee

3. Cross-Walk to the 13-Discipline Enterprise Agent Blueprint

Your existing 13-discipline framework already separates Foundation Engineering, Agentic Execution, and Governance/Safety/Observability. The table below makes it explicit where, within each discipline, a promptware-relevant governance control must be embedded — and what breaks if it is skipped.

Macro-Category	Discipline	Governance Embedding Point	Failure Mode if Skipped
Foundation	Prompt Engineering	Explicit system-level instruction hierarchy: user content is never granted the same authority as operator instructions	Injected text in a document or email is silently obeyed as a command
Foundation	Context Engineering	Content-source tagging so the model can distinguish "trusted operator instruction" from "retrieved/untrusted content"	Model cannot distinguish a poisoned search result from a genuine instruction
Foundation	Memory Engineering	Write-access controls on long-term memory; sanitization before persistence	A single injected instruction persists and re-triggers across future sessions
Foundation	Harness Engineering	Sandboxed execution; output validation before any tool call is dispatched	A manipulated "thought" step becomes an unchecked real-world action
Execution	Tool Layer Engineering	Least privilege, scoped API keys per task; explicit deny-lists for irreversible actions	Agent has more real-world reach than the task requires
Execution	Orchestration Engineering	Routing rules that force high-risk paths through a human or a stricter model	Silent routing of a sensitive request without escalation
Execution	Agent Design Engineering	Role/capability scoping — each agent has a narrow, auditable job description	Scope creep: an agent designed for FAQs ends up approving refunds
Execution	Multi-Agent Systems	Inter-agent message validation — one agent's output is untrusted input to the next	Injection in Agent A's output propagates and compounds through Agent B and C
Governance	Safety Engineering	Hard-coded limits below the instruction layer (cannot be overridden by any prompt)	A cleverly worded prompt talks the system past its own guardrails
Governance	Observability Engineering	Full trace logging of every reasoning step and tool call, reviewable post-incident	An incident cannot be reconstructed or attributed after the fact
Governance	Alignment & Policy Engineering	Mapping to PDPA/BNM/MCMC/NAII obligations built into the system prompt and review cycle, not just a legal appendix	Technically working system that is non-compliant or misaligned with institutional values

4. Role-by-Role Governance Charter

Governance fails when it is "everyone's responsibility," which in practice means no one's. Each role below has a specific, non-transferable question.

Role	Non-Transferable Governance Question	Evidence Required
Data / ML Engineers	Is the training and retrieval data classified, consented, and bias-screened?	Data lineage log; PDPA consent basis; bias audit report
Prompt / Context / Harness Engineers	Can the system distinguish an instruction from the operator vs. content from the world?	Instruction-hierarchy design doc; context-tagging spec
Solution Architect / Agent Designer	What is this agent's exact tool radius, and why does it need permission for granted?	Least-privilege tool manifest; agent job description
AI Safety / Red Team	Has this system been adversarial tested for injection and jailbreak resistance before go-live?	Red-team report with pass/fail thresholds
AI Governance Lead / DPO	Can every decision be traced to a model version, data source, and accountable owner?	Model card; lineage registry; audit trail sample
Legal & Compliance	Does this system meet PDPA 2010, sector regulator (e.g. BNM), and MCMC obligations for its use case?	Regulatory mapping memo; DPIA where applicable
CTO / AI Lead (Foundation focus)	Are instructions precise and auditable? Do agents see only what they're authorized to see? Can they loop indefinitely?	Sign-off on Foundation Engineering gate (Section 2, Stages 1–3)
COO / CPO (Execution focus)	Which external systems can agents touch, and who approves handoffs between systems and humans?	Sign-off on Deployment gate (Section 2, Stage 5)
CRO / General Counsel / CEO / Board (Governance focus)	What can our agents never do? Can we trace every decision for audit? Do they act in accordance with our values and regulations?	Sign-off at AIG gate (Section 2, Stage 6); quarterly governance committee minutes

5. Regulatory Anchors

5.1 Malaysian Context

•   PDPA 2010 — consent basis, data subject rights, and cross-border transfer rules for any personal data entering the pipeline.

•   Bank Negara Malaysia (BNM) guidance — applicable where the solution touches financial services; risk management and outsourcing expectations extend to AI vendors and model behavior.

•   MCMC — relevant where the system generates or distributes content or interacts with the public over regulated communications channels.

•   National AI Framework / National AI Office (NAIO) the emerging national reference point for AI governance expectations; useful as the shared vocabulary when briefing GLC and enterprise clients under MD2030.

5.2 International Reference Frameworks (useful for benchmarking, not direct obligation in Malaysia)

•   EU AI Act — risk-tiering methodology (unacceptable / high / limited / minimal risk) is a useful lens even outside EU jurisdiction.

•   Singapore IMDA guidelines — practical, sector-neutral AI governance guidance with strong regional relevance.

•   WEF Agentic AI Governance Framework — specifically addresses the autonomy and multi-agent risks of this protocol's Section 3 maps to.

6. Governance Maturity Roadmap

Mirroring the five-stage adoption roadmap already used for the technical blueprint, governance maturity should be staged rather than attempted all at once:

Stage	Governance Focus	Exit Criteria
1. Literacy	Everyone touching the system can explain, in plain language, what prompt injection is and why instruction/data separation matters	Team completes governance literacy briefing; no unowned AI initiatives in flight
2. Control Mapping	Every discipline in Section 3 has a named control and a named owner	Completed control-to-owner matrix, reviewed by AI Governance Lead
3. Safety Baseline	Red-team pass on injection/jailbreak resistance before any production deployment	Documented red-team report meeting minimum thresholds
4. Operational Governance at Scale	Trace logging, observability dashboards, and human-in-the-loop gates running live across all deployed agents	30+ days of clean audit trail with no unexplained gaps
5. Board-Level Assurance	Quarterly governance reporting to CRO/GC/CEO/Board with incident history and control effectiveness	Standing governance committee cadence; board sign-off obtained

 

 

7. Implementation Checklist

•   Classify every data source before ingestion; log onto the PDPA consent basis.

•   Write an explicit instruction hierarchy — operator instructions are never equal in authority to retrieved or user-supplied content.

•   Tag context by trust level so the model (and downstream reviewers) can tell instruction from data.

•   Grant tools on a least privileged basis; write down why each permission is needed.

•   Insert a human checkpoint before any irreversible or high-value action.

•   Red team for injection and jailbreak resistance before every production release, not just at initial launch.

•   Log every reasoning step and tool call; make the trace reviewable after an incident, not just during one.

•   Assign one named owner per discipline in Section 3 — no shared or ambiguous ownership.

•   Hold scheduled (not ad hoc) metric reviews across data, model, and deployment layers.

•   Report control effectiveness — not just system uptime — to the C-Suite and Board on a fixed cadence.

8. Closing Note

The goal of this protocol is not to claim invulnerability — that claim would itself be a governance failure, since it discourages the ongoing vigilance, the system actually needs. The goal is what your own closing slide already states: True Enterprise AI is Accountable AI. A system with distributed, independently-owned controls at every lifecycle stage will fail more often at any single point but is far less likely to fail catastrophically or invisibly — which is the realistic, defensible standard to present to clients, regulators, and the Board.