Edition 9 · 15 April 2026 · Subscribe on Substack
At RSA Conference 2026 this month, Astrix Security made a set of announcements that should be required reading for any security leader deploying AI. Their headline statistic frames the problem precisely: non-human identities now outnumber human users by 100 to 1 in the average enterprise environment. Every AI agent, every automation, every SaaS integration authenticates through a web of OAuth tokens, service accounts, API keys, PATs, and MCP server connections. Collectively, these are Non-Human Identities -- and they are invisible to the PAM and IGA solutions that most organisations have invested in for the past decade.
Astrix's new four-method discovery architecture attempts to address this at scale. Their platform now ingests data from AI platform integrations directly (covering Copilot, Bedrock, Vertex, OpenAI, Agentforce), supplements this with NHI fingerprinting across cloud, SaaS, DevOps, and identity provider layers, adds sensor telemetry from EDR tools including CrowdStrike and SentinelOne, and provides a BYOS extension for proprietary systems. The result is comprehensive inventory -- sanctioned agents, shadow agents, and MCP servers alike -- mapped to the human owner responsible for each one and the permissions it carries.
Source: Astrix Security RSAC 2026 · Help Net Security
What makes this practically relevant for the organisations IR works with -- NGOs, health charities, arms-length public bodies -- is the shadow adoption dynamic. These are environments where staff regularly connect personal productivity tools to organisational systems without IT oversight. An Admiral Nurse who connects an AI transcription tool to her Microsoft account. A fundraising team member who builds a Zapier automation linking the donor CRM to an OpenAI assistant. A finance officer who installs Cursor on their laptop and connects it to the organisation's GitHub repository. Each of these creates one or more NHIs -- service accounts, OAuth apps, API keys -- that carry real permissions and generate no alert in any monitoring system the organisation has.
The governance gap is structural, not operational. Astrix's new Agent Policies feature -- allowing security teams to define allow, flag, and block rules scoped by user, department, platform, and resource type, evaluated before an agent action executes -- is the right direction. But the prerequisite is discovery: you cannot govern what you cannot see. For most mission-driven organisations, the first question to answer is not "do we have the right controls?" but "do we even know what NHIs exist in our environment?"
Source: ReversingLabs · Barracuda Networks · NHI Management Group
The remaining provisions of the EU Artificial Intelligence Act become applicable on 2 August 2026. This is the major milestone: the date from which obligations on high-risk AI systems apply to all operators, including those outside the EU whose systems are used within it. Conformity assessments must be completed, technical documentation finalised, and relevant systems registered in the EU database. For any organisation that has deployed AI in a context touching EU data subjects -- which includes most UK charities and NGOs with European operations, donor bases, or research partnerships -- this is not an abstract compliance matter.
The practical reality for deployer organisations (as distinct from developers or providers) is that the obligations are less about technical certification and more about documentation, governance, and accountability chains. Can you describe what your AI system does and does not do? Can you demonstrate that a human was in the loop for consequential decisions? Do you have a DPIA that reflects the AI-specific risks? Can you show that you evaluated your supplier's system before deployment? These are the questions the Act requires you to be able to answer -- and most mid-size charities and public bodies cannot currently answer them for every AI system they operate.
Source: Kennedys Law · Orrick: 6 Steps Before 2 August · MHRA AI Medical Device Framework
Progress in zero-knowledge machine learning continued steadily this quarter, without the headline-grabbing announcements of last year. Giza Technology's LuminAIR framework -- built on StarkWare's STWO prover using Circle STARKs -- has moved into its GPU acceleration phase, with the goal of making zkML proofs fast enough for practical deployment in live systems rather than theoretical demonstrations. The framework allows an AI agent to generate a cryptographic proof that its decision or output genuinely came from a specific, named model -- rather than a modified or substituted version -- without revealing the model weights or input data.
The practical application IR continues to track most closely is audit trail integrity for clinical and regulated AI. Under the EU AI Act's documentation requirements, deployers of high-risk AI systems need to be able to demonstrate that outputs were generated by the declared system. Under NHS clinical safety standards, the "it only suggests, never decides" principle only holds if there is an auditable record of what the system actually produced. zkML offers a path to cryptographically verified audit trails -- not just logs that can be altered, but proofs that cannot be retrospectively falsified. EZKL, the other primary open-source zkML engine, released further GPU performance improvements in Q1 2026, bringing proof generation times for smaller models into the range where pilot deployments become feasible.
The honest caveat remains: for large language models and complex multi-step reasoning chains, the compute cost of zkML proofs is still prohibitive outside well-resourced research and DeFi contexts. The near-term practical value for mission-driven organisations is narrower -- verifying specific high-stakes inference steps (a triage decision, a safeguarding flag, a fundraising targeting output) rather than end-to-end model verification. Worth watching rather than acting on immediately, but the trajectory is towards production viability within the strategy horizon.
Source: StarkWare: Giza x S-two · EZKL releases · Definitive Guide to zkML
The NHI security challenge described above creates a specific forensics problem: when an AI agent takes an unintended action -- exfiltrating data, escalating privileges, making an unauthorised API call -- the traditional security tooling response is to generate an alert. The alert says something happened. It does not say why, or which upstream cause in a chain of agent decisions and delegations led to it. In environments where agents are operating at machine speed across dozens of interconnected systems, alert-based detection produces two failure modes: either alert fatigue from too many low-fidelity signals, or delayed detection because the root cause happened several steps before the observable behaviour.
The causal ML approach -- drawing on work from the Alan Turing Institute, IBM Instana's anomaly detection, and the DoWhy/CausalML library ecosystem -- addresses this by attempting to reason about what change in the environment caused an observed outcome, rather than simply correlating the outcome with nearby events. In an agentic context, this means modelling the causal graph of agent actions: which permission grant led to which downstream capability, which tool invocation triggered which data access, which MCP server connection created which lateral movement opportunity. The output is a root cause chain, not a list of correlated alerts.
This remains an area where the research is ahead of the tooling for most organisations. But the framing matters for procurement and governance decisions being made now. When evaluating AI security tooling -- whether NHI platforms, SIEM integrations, or agentic monitoring solutions -- "does this tell me why something happened or only that it happened?" is a question worth asking. Organisations that build causal reasoning into their security evaluation criteria now will make better decisions about which tools to invest in as the market matures.
Run an NHI discovery exercise before the end of Q2. You do not need a platform to start: pull a list of all OAuth applications connected to your Microsoft 365 or Google Workspace tenant, map each to the human who authorised it, and check when each was last used and what permissions it holds. The results will almost certainly surface integrations that nobody remembers authorising, tokens that were never rotated, and service accounts that were never offboarded. That is your NHI attack surface in miniature -- and it is almost certainly larger than you expect. For organisations deploying AI agents, run the same exercise against every agent's authentication credentials before the 2 August EU AI Act deadline forces you to.
The 2 August EU AI Act deadline is 15 weeks away. If your organisation deploys AI systems that affect EU data subjects -- donors, service users, research participants -- and you cannot currently answer "what AI systems do we operate, who approved them, and what governance is in place?", that is a board-level risk item, not an IT matter. Start with a simple inventory: ask your technology lead to list every AI tool the organisation uses or has used in the past 12 months, who authorised it, and whether a DPIA exists. The gap between what that list contains and what your board knows about is likely to be material.