The IR Digest — Edition 10 · Intelligent Resilience

This edition focuses on the governance gap hiding in plain sight: every AI connector your staff adds to their workflow creates a non-human identity that your security tooling cannot see. We cover Keeper Security's RSAC findings on NHI governance failures, the minimum-useful-access principle as a practical countermeasure, the emerging MCP security threat surface, and a brief update on EU AI Act readiness as August approaches.

Agentic AI Security

The Connector Budget: Why Every Tool You Add to an AI Workflow Is Also an Identity You Have to Govern

Most organisations thinking about AI security are focused on the AI itself — the model, the outputs, the hallucination risk. The governance gap that is actually widening fastest is not in the model layer. It is in the connections surrounding it.

Every time a staff member connects an AI assistant to an external service — a calendar, a CRM, a document store, a communication platform — that connection is authenticated through an OAuth token, a service account, or an API key. The connection persists after the task is complete. The token is rarely rotated. The permissions are rarely scoped to the minimum required. And the whole arrangement creates a Non-Human Identity: a machine credential that carries real access rights and generates no alert in any privileged access management system the organisation has invested in.

This is not a theoretical risk. It is what the ClawHavoc supply chain attack demonstrated at scale last month — malicious packages exploiting the trusted NHIs that AI agent frameworks hold. It is what the Moltbook breach illustrated: a third-party integration compromised, then used to pivot laterally through every environment the integration had legitimate access to. The attack surface is not the AI. It is the web of identities the AI operates through.

76%

of organisations with AI tool access do not govern those identities under PAM policies

53%

cite lack of visibility into AI and machine access as their top NHI risk

32%

are unsure whether they have already had an NHI security incident

The concept IR has been applying to this problem is what some are now calling the connector budget — the deliberate, per-workflow discipline of connecting only the tools a given agent genuinely requires for that task, and disconnecting them when the task is complete. It is minimum-useful-access applied to agentic workflows: the same principle that underlies least-privilege in traditional identity governance, adapted for an environment where identities are created and discarded in minutes and are invisible to the tools designed to govern them.

The connector budget framing is practically useful because it gives non-technical leaders a concrete question to ask: "For this AI workflow, which systems does it need to touch, and which systems does it currently have access to?" The gap between those two answers is your unnecessary NHI attack surface. In most organisations that have adopted AI productivity tools in the past 18 months, that gap is significant — and entirely unaudited.

The governance principle. Minimum useful access per workflow: connect only what is needed, scope permissions to the task, revoke or rotate after use. This maps directly onto OWASP LLM08 (Excessive Agency) and is the prerequisite for any meaningful NHI governance programme. The tooling to enforce it at scale — Astrix's Agent Policies, Keeper's NHI vaulting, and emerging MCP gateway architectures — is maturing rapidly. But the governance principle does not require a platform to implement. It requires a policy decision and someone accountable for enforcing it.

Agentic AI Security

MCP Security: The Protocol Connecting Your AI to Everything Has Become a Primary Attack Surface

Model Context Protocol has become the de facto standard for connecting AI agents to external tools and data sources. Anthropic introduced it, and adoption has been rapid — it is now the plumbing behind most enterprise AI agent architectures, including Microsoft Copilot integrations, OpenAI tool use, and a growing catalogue of third-party agents. The problem is that MCP was designed to optimise developer velocity and interoperability, not security enforcement. That design choice is now producing consequences at scale.

The two attack vectors most active in Q1 2026 are tool poisoning and indirect prompt injection via MCP connectors. Tool poisoning exploits the fact that an MCP tool's description — the text the AI model reads to understand what the tool does — is not validated or signed. An attacker who compromises an MCP server, or publishes a malicious MCP tool in a community repository, can embed instructions in the tool description that are invisible to the user but followed by the model. The model calls what it believes is a search function; the function exfiltrates credentials. There is no observable user action because the user never gave one.

The pivot problem. An MCP server that is poorly authenticated or misconfigured becomes a universal pivot point: an attacker who controls an MCP server can, in principle, control every AI agent connected to it. In enterprise environments where a single MCP deployment serves multiple agents across multiple departments, the blast radius is comparable to a compromised domain controller. The OWASP MCP Top 10, published in early 2026, catalogues the full attack surface — tool poisoning, privilege escalation, supply chain substitution, sampling-based injection, and credential theft via ambient context. For organisations deploying or procuring AI agents, this should be required reading before any production deployment.

The practical implication for mission-driven organisations is not that MCP should be avoided — it is that MCP deployments require the same security evaluation as any other privileged integration. Questions to ask before any MCP-connected deployment: Where does this MCP server run, and who controls it? What permissions does the agent hold on each connected system? Has the tool catalogue been reviewed for unsigned or community-sourced entries? Is there a gateway or audit layer between the agent and the tools it can call? For most organisations, these questions have not been asked, because MCP adoption has happened faster than security evaluation cycles can keep pace with.

A useful operational governance artefact for organisations beginning to address this is a connector budget policy — a documented, per-workflow statement of which connectors are authorised, what permissions they hold, who owns them, and when they were last reviewed. Below is a minimal structure that works for most NGO and charity environments:

# IR Connector Budget Policy — Minimal Template # One entry per authorised AI workflow. Review quarterly. workflows: - name: "Fundraising Supporter Comms Agent" owner: "Head of Fundraising" authorised_connectors: - CRM (read: donor records; write: communication log)" - "Email (send-only; no inbox read)" explicitly_blocked: - "Finance systems" - "HR records" - "External file storage" last_reviewed: "2026-04-01" next_review: "2026-07-01" nhi_credentials: - type: "OAuth app" registered_in: "Microsoft Entra ID" last_rotated: "2026-03-15"

The value of this template is not the YAML — it is the discipline of making the inventory visible and assigning ownership. Most security incidents involving AI agents do not exploit novel vulnerabilities. They exploit unmanaged credentials in systems nobody is monitoring, because nobody knew the credentials existed.

Regulatory

EU AI Act: 15 Weeks to Go — The AI Register Is Still the Starting Point Most Organisations Are Missing

The 2 August 2026 deadline for the EU AI Act's high-risk provisions is now 15 weeks away. The compliance conversation in most UK organisations has not moved materially since Q1. The organisations that are ahead are not those with the most sophisticated compliance programmes — they are those that completed one foundational step first: building a current register of every AI system they operate, who authorised it, and what decision it influences.

Everything else in EU AI Act compliance — conformity assessments, DPIAs, technical documentation, human oversight demonstrations — depends on that register existing. You cannot assess whether a system is high-risk if you do not know the system exists. For organisations that have adopted Microsoft Copilot, AI-assisted case management tools, donor analytics platforms, and conversational chatbots in the past 18 months without centralised governance, the register is likely to surface systems that nobody in the leadership team knows about. That is the gap to close in the next 15 weeks, not the documentation of systems you already have under governance.

For UK organisations. Direct EU AI Act obligations apply where your systems affect EU data subjects — donors, service users, research participants, or beneficiaries with EU residency. That is a broader category than many UK charities realise. Separately, the MHRA National Commission on AI in Healthcare is expected to publish its framework in 2026, and NICE and CQC are both signalling that explainability and human oversight will be hard requirements for clinical AI. Organisations building governance frameworks now — voluntarily, in advance of mandatory UK requirements — will be significantly better positioned when UK obligations land. Retrofitting governance is always more expensive than building it in at the start.

Horizon Watch

NHI Governance Tooling: What the RSAC 2026 Field Report Tells Us About Where the Market Is Heading

RSAC 2026 was notable for the volume of vendors now positioning explicitly around NHI governance — a category that barely existed as a named market segment two years ago. The Cremit RSAC field report catalogues the main approaches: dedicated NHI platforms (Astrix, Entro, Clutch, Oasis) competing for position against extensions to existing PAM, IGA, and CSPM tooling from CyberArk, SailPoint, and Wiz respectively. The framing contest matters, because it determines where the budget lands.

The honest assessment for most mid-size NGOs and charities is that purpose-built NHI platforms are ahead of where your organisation currently needs to be. The prerequisite is visibility — and the foundational visibility exercise (OAuth app audit in Microsoft 365 or Google Workspace, service account review, API key inventory) does not require a platform. It requires an afternoon and someone with admin access. The platforms become valuable when you have completed that inventory and found the scale of the problem warrants automated discovery and continuous monitoring. Most organisations will find the inventory exercise alone produces enough actionable findings to occupy their security function for a quarter.

For CISOs and Technical Leaders

Run an OAuth application audit this fortnight. Pull every OAuth app connected to your Microsoft 365 or Google Workspace tenant — your admin portal has this under Enterprise Applications or Connected Apps. For each: who authorised it, when, what permissions it holds, and when it was last used. Filter for apps with write permissions to mail, calendar, files, or SharePoint. Any app that has not been used in 90 days and still holds write permissions is unnecessary NHI attack surface. Revoke it. Then scope the same exercise to any AI agent framework your organisation is running — OpenClaw, Cursor, Copilot Studio, or similar. Map every credential each agent holds to a named human owner. The inventory will take less time than you expect. What you find in it may not.

For Finance Directors and Non-Specialist Leaders

Ask your technology lead this question: "Can you show me a list of every application and tool that currently has access to our systems through an automated connection — not through a human logging in, but through a background credential?" If they can produce that list quickly, your NHI governance is ahead of most organisations at your scale. If they cannot, or if producing it would take significant effort, that is a material gap in your security posture — and it is the gap that AI-assisted attacks are now most actively exploiting. The 2 August EU AI Act deadline makes closing it both a security priority and a compliance requirement simultaneously.