News

What the Five Eyes agentic AI guidance means for connecting an assistant to a deal room

Six cybersecurity agencies published joint guidance on 1 May 2026 advising organisations not to grant AI agents broad or unrestricted access to sensitive data. A due diligence data room is one of the most concentrated collections of sensitive data a firm will ever assemble, and the access inside it is deliberately unequal. That makes the connection between an assistant and a room a permissions problem before it is an AI problem.

By the CogniSuite team

By the CogniSuite team

What the agencies actually published

On 1 May 2026, six cybersecurity agencies released joint guidance titled Careful Adoption of Agentic Artificial Intelligence (AI) Services. The signatories are the US Cybersecurity and Infrastructure Security Agency and the National Security Agency, the Australian Signals Directorate's Australian Cyber Security Centre, the Canadian Centre for Cyber Security, New Zealand's National Cyber Security Centre and the UK National Cyber Security Centre. It is the first time all five nations have issued coordinated guidance aimed specifically at agentic deployments.

It reads as a deployment document rather than a research paper. The recommendation that matters most to anyone considering wiring an assistant into a deal room is the one about access: limit agent autonomy by ensuring agents are not granted broad or unrestricted access, especially to sensitive data or critical systems. Sitting alongside it are instructions that are equally operational. Give each agent its own secure, verifiable identity. Configure least-privilege access so an agent holds only the permissions a given task requires. Use temporary credentials for sensitive actions. Monitor internal processes, not only inputs and outputs. Keep a human approval step in front of high-impact or irreversible actions. Start with lower-risk work and widen autonomy only as controls mature.

The risk groupings translate to deal work with almost no adaptation. Privilege and identity risk covers agents that accumulate more permission than their role justifies, and are then exploited or simply misused. Behavioural risk covers actions that are technically permitted and still wrong. Design and configuration risk covers the expanded attack surface that arrives with external tools and integrations. And the guidance is blunt about event records: logging that does not capture what the agent did internally makes auditing and incident response harder than the deployment diagram suggests.

Why a data room is the hardest version of this

Most enterprise systems are built so that everyone inside the tenant can see roughly the same things. A data room is built on the opposite assumption. Different bidders see different folders. The sell-side team's internal working files are not for the buyer. Clean-team material is walled off from the commercial team on both sides. On a buy-side mandate the party who is external to the room is the seller, not the buyer. Every one of those boundaries exists because a lawyer, a regulator or a signed agreement put it there, and several of them concern material non-public information.

A room where everybody sees everything is not a data room. It is a shared drive with a login page.

So when someone proposes connecting an AI assistant to the room, the useful question is not whether the assistant can read the documents. It obviously can. The question is: as whom.

The pattern the guidance warns about

The pattern is easy to describe because it is the one that is easiest to build. You create a service account, grant it read access across the room so the assistant is never stuck, hand its credential to a general-purpose assistant, and let people ask questions. The demo is excellent. Every question gets an answer, because every document is in reach.

The failure mode is that the answers are correct and out of scope. There is no denied download in the log, no permission error, no obvious incident. There is a sentence in a chat window containing a number that the person reading it was never cleared to see, sourced from a folder they cannot open in the file browser two tabs away. Standing room-wide access does not leak files. It leaks facts, which are harder to claw back and harder to notice.

Indirect prompt injection sharpens this considerably. In December 2025 the UK NCSC published an assessment arguing that prompt injection will probably never be mitigated the way SQL injection was, because a language model has no internal boundary between instructions and data. Its framing is that models are "inherently confusable" deputies, and that the risk can be reduced but not removed. Its conclusion is the practical part: "Design protections need to therefore focus more on deterministic (non-LLM) safeguards that constrain the actions of the system, rather than just attempting to prevent malicious content reaching the LLM."

A data room is full of documents supplied by counterparties and their advisers. That is untrusted content by definition. Combine untrusted uploaded content with a credential that can read the whole room and you have assembled the confused deputy scenario in its textbook form. OWASP's treatment of excessive agency arrives at the same control from the application side: track user authorisation and security scope so that actions taken on behalf of a user execute in the context of that specific user, with the minimum privileges necessary.

Several incumbent platforms have announced connectors that let an outside assistant query the room. The right question to put to any of them is not whether the connector is encrypted. It is whose permissions the retrieval runs under.

What permission-scoped actually requires

Four properties, and all four have to hold.

The same rules as the human, not a parallel copy. The check that decides whether a document may be retrieved should be the same check that decides whether that person can open the folder in the browser. Two implementations of one policy drift, and the copy that drifts is always the newer one that fewer people test.

Applied before ranking, not after. This is the distinction that gets glossed over. Post-filtering means the retriever searches the entire room, ranks the results, and then removes the ones the asker cannot see. It looks equivalent and is not. The candidate set was shaped by documents the user has no right to, the returned set silently shrinks, and the whole design depends on the removal step never being skipped. Pre-filtering means a document the user cannot read never becomes a candidate at all, so the top results are the top results among permitted material. Filtering the generated answer instead of the retrieval is worse again: that is redaction after exposure.

Fail closed when scope cannot be resolved. If the system cannot positively determine which side a recipient sits on, or which organisation owns a request list, the correct behaviour is to ground on nothing. An empty context and a thin draft is a recoverable failure that a human notices immediately. A fluent, well-grounded answer built against the wrong access rules is not recoverable, because nothing about it looks wrong.

Scope to the audience, not only the asker. When the output is destined for the other side, the grounding set must be what that side may read, not what the banker drafting it may read. Where several counterparties can see the same request list, the correct set is the intersection of what all of them may read, not the union.

How the room does it

Retrieval in CogniSuite runs through a single shared path used by every AI feature, and the folder access check is an input to that path rather than a step after it. A document the asking user cannot read is never admitted to the candidate set, so the returned results are the top matches among permitted documents. That access check is the same four-grade folder resolution the file browser uses, with per-user overrides layered over organisation grants layered over inherited parent-folder grants. The room knows whether the mandate is buy-side or sell-side, so the counterparty is identified correctly rather than assumed to be the buyer.

Each deal is a physically separate database served on its own subdomain. Cross-deal retrieval is not a rule the model is asked to follow. There is nothing on the other side of the query to reach.

For counterparty-facing drafts, the grounding set is scoped to what the receiving side may read, using the organisation-level baseline so that a per-user override cannot widen it. Multiple counterparty viewers produce an intersection. If the owning organisation cannot be positively resolved, the system denies rather than falling back to the drafting banker's own access.

After generation there is a deterministic check that does not involve a model. Counterparty-facing drafts are produced as structured output, and every citation is verified server-side: the cited document must be in the permitted set, and the quoted text must actually appear in that document. Citations that fail are dropped. An affirmative answer that survives with no verifiable citation is replaced with a note routing it for human review rather than shown. That is the non-model safeguard the NCSC assessment argues for, doing the job that prompt instructions cannot.

On identity, the assistant runs under the asking person's own session. There is no service account holding room-wide read, and no general tool surface exposed for an external assistant to call into. Single sign-on is available as OpenID Connect, authorisation code with PKCE, with a per-firm email domain allowlist. It is opt-in per workspace and sits alongside the emailed one-time code rather than replacing it.

Limits worth stating plainly

Retrieval treats folder access as a binary. Any folder the user may read at all is eligible, including folders granted at view-only or watermark-only level. So an answer can quote text from a document the reader may only see watermarked and may not download. Watermarking covers PDF, Word, images, spreadsheets and presentations, and a file that cannot be watermarked is refused rather than served clean, but a watermark protects a file, not a sentence lifted out of it. Firms that need a stricter separation should set those folders to no access rather than view-only.

Prompt-level guardrails are mitigation, not a boundary. Input sanitisation and instruction blocks about treating document text as data are worth having and are not a security control. The controls are the separate per-deal database, the access check applied before retrieval, and the server-side citation verification.

The audit trail records the actor, action, target and source IP for document views, downloads, permission changes and AI questions, and it is exportable. It is not cryptographically tamper-evident, and it is readable by the advising firm's team rather than by counterparties. It is an oversight tool for the deal team, not a mutual evidentiary record, and firms with an obligation to prove disclosure to a third party should plan accordingly. Chat history is held client-side, so a conversation is not itself part of the deal record beyond the logged question event.

Questions to ask before connecting anything

  • Whose identity does the retrieval run under, the asking person's or a service account's?
  • Is the permission check the same one the file browser uses, or a second implementation?
  • Is it applied before ranking or after?
  • What happens when the system cannot resolve scope? Does it deny, or does it fall back to something broader?
  • When output is destined for a counterparty, whose access defines the grounding set?
  • What is written to the audit trail, who can read it, and can it be altered?
  • Which of these are enforced in code, and which are asked for in a prompt?

The last one separates most claims from most implementations. The joint guidance is asking organisations to answer it before the connector goes live rather than after. For how the underlying controls are built, see /security.

Sources

General information, not legal, tax or financial advice. For how CogniSuite handles security and access, see Security. To see it on a live deal, book a walkthrough.

← All articles