# DRAFT RESPONSE — UK Information Commissioner's Office (ICO) Call for Evidence on Agentic AI

**Status:** **DRAFT FOR OWNER REVIEW & APPROVAL ONLY — NOTHING SENT**  
**Prepared Date:** 6 November 2026  
**Consultation Deadline:** 18 November 2026  
**Respondent Organisation:** Pharoah Technology Ltd (Founder: Phil Pereira)  
**Technical Reference System:** Pharaoh Agent Shield (`pharaoh-agent-shield`) — Deterministic Runtime Enforcement & Governance Gateway for Model Context Protocol (MCP) Agents  
**Repository & Drive Archive Path:** `Pharoah Technology/Compliance/ICO_Agentic_AI_Call_for_Evidence_2026-11/ICO_AGENTIC_AI_CALL_FOR_EVIDENCE_DRAFT_2026-11-06.md` (`docs/compliance/ICO_AGENTIC_AI_CALL_FOR_EVIDENCE_DRAFT_2026-11-06.md`)

---

## 1. Respondent Profile & Basis of Technical Evidence

Pharoah Technology Ltd builds deterministic security, privacy, and runtime governance infrastructure for autonomous software systems. Our submission responds to the Information Commissioner's Office (ICO) Call for Evidence on Agentic AI (closing **18 November 2026**), building directly on the technical risk taxonomy established in the ICO's ***Tech Futures: Agentic AI* report (published 8 January 2026)**.

Every technical position in this submission is grounded in working, open-inspectable software implemented in **Pharaoh Agent Shield (`pharaoh-agent-shield`)**—a runtime control point sitting between AI agents and external tool servers speaking the Model Context Protocol (MCP). We do not speculate on unbuilt roadmap items; where a capability is Phase 2 (such as short-lived upstream OAuth credential brokering), we state that boundary explicitly.

---

## 2. Executive Position: Why Post-Hoc Observability and Prompt Guardrails Fail UK GDPR Duties in Agentic AI

In traditional generative AI chatbots, a model produces text for a human reader who decides whether to act. In **agentic AI**, the model invokes external tools (databases, CRMs, email servers, billing APIs, shell environments) across multi-step execution loops.

Our operational testing confirms three structural properties relevant to UK GDPR enforcement:

1. **Prompt instructions are not a security or data-protection boundary (UK GDPR Art. 25 & Art. 32).**  
   When an agent reads untrusted external data (a support ticket, web page, or third-party MCP tool description), instruction-shaped content in that data (`PROMPT_INJECTION_IN_TOOL_OUTPUT`, `TOOL_METADATA_INJECTION`) can steer the model into invoking high-impact tools or exfiltrating personal data. Relying on another LLM prompt to police an agent in the critical path introduces non-determinism, latency, and a second prompt-injection surface.
2. **Post-hoc tracing is not runtime control (UK GDPR Art. 5(2) & Art. 22).**  
   Recording in an observability dashboard that an agent deleted a customer record, emailed 500 individuals, or sent `PERSONAL_DATA` / `CREDENTIAL` material to an unapproved external endpoint *after* the HTTP/stdio call has executed does not prevent the breach. Enforcement must execute synchronously **before** the upstream tool is contacted.
3. **Discovery of a tool is not permission to invoke it (UK GDPR Art. 25 Data Protection by Default).**  
   MCP servers dynamically advertise tools via `tools/list` and can mutate tool schemas or descriptions after initial review (`TOOL_DRIFT`). Treating dynamic tool discovery as implicit authorisation violates data protection by design and by default.

---

## 3. Concrete Technical Controls Addressing the ICO's Agentic AI Risk Areas

Pharaoh Agent Shield demonstrates that four deterministic runtime controls—operating in **under 1 millisecond on average (`< 1 ms`) with zero LLM calls in the critical path**—materially resolve the accountability, human-oversight, reconstructability, and supply-chain risks highlighted in *Tech Futures: Agentic AI* (8 January 2026):

### Control 1 — Agent Register with a Named Accountable Human Owner per Agent
* **ICO Risk Addressed:** Diffusion of accountability when autonomous or semi-autonomous agents execute chains of actions without a clearly identified human principal (*Tech Futures: Agentic AI*, 8 Jan 2026; **UK GDPR Article 5(2)** accountability).
* ** EU AI Act Alignment:** **Regulation (EU) 2024/1689** (published *OJ L* 12 July 2024, in force 1 August 2024), **Article 50(1)** (applicable 2 August 2026) and **Article 14** (human oversight).
* **Live Technical Implementation in Agent Shield:**
  * Every agent registered in `shield_agents` via `registerAgent()` must have a non-empty, named human owner (`owner_human_id`), alongside its declared `purpose`, `model`, `environment`, `status` (`ACTIVE`, `PAUSED`, `DISABLED`), and `approval_threshold_tier`.
  * When a tenant policy sets `requireRegisteredAgentOwner: true`, the policy engine's invariant layer blocks any tool call from an unowned agent (`AGENT_OWNER_REQUIRED`) before any tenant rule is consulted.
  * Every registration, owner reassignment (`setAgentOwner`), and threshold update (`setAgentApprovalThreshold`) writes an immutable event (`governance.agent.registered`, `governance.agent.owner_assigned`, `governance.agent.threshold_set`) to the tenant's hash-chained audit trail.

### Control 2 — Deterministic Approval Thresholds Holding Actions for Human Sign-Off
* **ICO Risk Addressed:** Nominal or "rubber-stamp" human-in-the-loop oversight where humans either approve vague intentions before concrete tool arguments are known, or are bypassed when an agent escalates from benign reads to consequential writes/deletes (*Tech Futures: Agentic AI*, 8 Jan 2026; **UK GDPR Article 22**).
* **EU AI Act Alignment:** **Article 50(1) & Article 50(4)** (applicable 2 August 2026 — deployer verification of external AI communications) and **Article 14(4)(d)–(e)** (intervening in or halting execution).
* **Live Technical Implementation in Agent Shield:**
  * Every tool is assigned a risk tier (`T0` read-only through `T4` destructive/financial/privilege-modifying), and every registered agent carries a configurable `approval_threshold_tier` (`T0`–`T4`, defaulting to `T3`), complemented by declarative argument matchers (`count-at-least`, `number-at-least`).
  * When an agent attempts a call at or above its approval threshold (for example, an agent with threshold `T2` attempting an external post or email, or a bulk send exceeding 20 recipients), the gateway halts the call (`REQUIRE_APPROVAL`) and creates a structured approval record in `shield_approvals`.
  * **Cryptographic Action Binding & Single-Use Consumption:** The approval record binds to the SHA-256 `request_hash` of `{ tool, server, arguments }`, displays the classified data categories (`PERSONAL_DATA`, `CUSTOMER_DATA`, `FINANCIAL_DATA`, `HEALTH_DATA`) and target destination with any detected secrets redacted, and is marked `CONSUMED` upon first execution. If an agent alters a single argument and replays the approval, the gateway rejects the replay and raises a `HIGH`-severity `APPROVAL_MISMATCH` alert.

### Control 3 — Exportable, Tamper-Evident Action Log Reconstructing What Each Agent Did
* **ICO Risk Addressed:** Inability of data controllers to reconstruct multi-step autonomous agent behaviour for UK GDPR **Article 5(1)(a)** transparency, **Article 5(2)** accountability, **Article 15** data subject access requests (DSARs), **Article 30** records of processing, and **Article 33** breach investigations—without turning the audit log itself into a plaintext secret leak.
* **EU AI Act Alignment:** **Article 50(2)** (applicable 2 August 2026 — machine-readable provenance of AI-assisted outputs at the action layer) and **Article 12** (automatic logging over system lifetime).
* **Live Technical Implementation in Agent Shield:**
  * Agent Shield stores no raw prompt transcripts or plaintext secret values in its call or audit tables; arguments are represented by cryptographic hashes (`request_hash`, `forwarded_hash`, `response_hash`), classified data labels, and structured redaction/transformation diffs.
  * `reconstructActionLog()` and `exportActionLog()` (`JSON`, `NDJSON`, `CSV`) reconstruct the complete chronological sequence per agent across sessions and correlation IDs (`correlation_id`), linking every tool call to its policy decision, reason codes, approval sign-off (`decided_by`, `decided_at`), and SHA-256 hash-chained audit sequence (`seq`, `prev_hash`, `hash`).
  * SQLite triggers (`shield_audit_no_update`, `shield_audit_no_delete`) forbid mutation or deletion of audit rows at the database layer, and `verifyAuditChain()` replays the SHA-256 chain from `GENESIS` on every export to prove log integrity.

### Control 4 — MCP Server Authentication & Liveness Verification
* **ICO Risk Addressed:** Shadow, unauthenticated, or abandoned third-party tool servers (`MCP` endpoints) exposing personal data or failing silently during autonomous workflows (*Tech Futures: Agentic AI*, 8 Jan 2026; **UK GDPR Article 25 & Article 32**).
* **Live Technical Implementation in Agent Shield:**
  * Every MCP server enters the inventory in `DISCOVERED` state (`SERVER_NOT_APPROVED`) and exposes zero tools to agents until explicitly approved by a human operator.
  * `assessAllServers()` and `checkAllServersAuthAndLiveness()` verify each server's authentication posture (`AUTHENTICATED` vs `UNAUTHENTICATED` — flagging HTTP servers that accept requests without authentication headers or that embed credentials in URLs) and endpoint liveness (`ALIVE` vs `DEAD` — flagging unreachable or non-responsive endpoints), raising `MCP_SERVER_UNAUTHENTICATED` and `MCP_SERVER_DEAD` alerts and recording `inventory.server.health_checked` audit events.
  * Tool definitions are fingerprinted (`SHA-256` over server, name, description, and JSON input schema); if an upstream server mutates a `T3` or `T4` tool after approval, Agent Shield revokes the tool's approval, quarantines the server (`QUARANTINED`), and blocks execution (`TOOL_DRIFT_DETECTED`).

---

## 4. Recommendations to the ICO for Regulatory Guidance on Agentic AI

Based on our engineering evidence, we respectfully recommend that forthcoming ICO guidance on Agentic AI distinguish between **advisory model guardrails** and **deterministic gateway controls**:

1. **Named Human Ownership per Agent:** Expect controllers deploying autonomous or tool-calling agents to maintain a live register binding each agent identifier to a named human owner and an explicit risk-tier approval threshold.
2. **Action-Bound Pre-Execution Human Sign-Off:** Clarify that under UK GDPR Article 22 and Article 25, "meaningful human review" for tool-using agents requires sign-off bound to the specific tool, destination, data classification, and cryptographic hash of the arguments *before* the side effect occurs—not a blanket pre-approval of an agent's high-level goal.
3. **Secret-Free, Hash-Chained Action Reconstruction:** Encourage controllers to log cryptographic argument hashes, data-class labels, redactions, and hash-chained decision receipts rather than dumping raw prompts containing personal data and credentials into third-party observability platforms.
4. **Explicit Tool-Server Trust & Auth Checks:** Expect controllers to treat external tool servers (such as MCP servers) as untrusted until approved, fingerprinted against schema drift, and verified for authentication and liveness.

---

**Submission Governance Note:**  
This document is saved in the repository (`docs/compliance/ICO_AGENTIC_AI_CALL_FOR_EVIDENCE_DRAFT_2026-11-06.md`) and staged for the Pharoah Technology Drive archive ahead of the **18 November 2026** deadline. An owner approval (`pharoah-task approval --action send`) has been raised for Phil Pereira. **No external transmission has been or will be made without explicit owner approval.**
