YOUR NEXT INSIDER ISN’T HUMAN
AI Agents, Classified Information and the Security Architecture Nobody Has Built Yet
For years we have treated the insider threat as a human problem. The disgruntled employee, the careless administrator, the contractor who kept access for too long, the person who copied something they should not have copied. Our security models grew around that picture. We created identities, roles, privileged accounts, separation of duties, Need-to-Know, security clearances, compartments, logging and procedures for removing access when somebody changes jobs or leaves the organisation.
Now we are putting something entirely different into the same environment.
AI agents are beginning to read our email, search document repositories, query databases, prepare correspondence, interact with ticketing systems, update records, use APIs and connect to external services. They are increasingly able to decide which tool to use and in which order, without a human approving every step. Calling them assistants is becoming misleading. An assistant suggests. An agent can act. That difference is where the security problem starts.
A conventional application does what somebody programmed it to do. An agent is different because part of its behaviour is determined at runtime by natural-language instructions, the information it encounters and the tools available to it. Give it access to Outlook, SharePoint, a project-management platform and an ERP system and you have not merely connected four applications. You have created a component that can move between four different information domains and decide, within limits, what is relevant to the task it has been given. The limits are what concern me, because in many organisations they are still surprisingly vague.
Microsoft is now recommending that agents should be treated as security principals in their own right, with dedicated identities, named owners, explicit purposes, narrowly scoped permissions, controlled access to tools and end-to-end auditability. That is an important change in thinking. It recognises that an agent acting across several systems is no longer simply functionality inside an application. It has become an actor within the security architecture. For Defence, government, critical infrastructure and organisations working with protected information, I think we need to go further.
Imagine a project manager in a defence company. Nothing particularly unusual about the role. She can access corporate email, project documentation, meeting calendars, procurement information, perhaps some engineering documentation and a customer collaboration environment. There may also be information about suppliers, travel, contracts and project milestones. Some of it is sensitive, some of it is ordinary business information, and the genuinely classified part of the programme may sit somewhere else entirely. Now give her an AI agent with access to the same information.
On paper, nothing has changed. The agent has not been given information the project manager was not entitled to see. If the access review is performed system by system, everything may look perfectly reasonable. In practice, something important has changed. The project manager does not continuously read every email, every calendar entry, every contract, every invoice, every supplier record and every project document and then correlate all of it with information available on the internet. She cannot. There is too much information and too little time.
The agent can.
That means identical access rights do not necessarily produce identical capability. A human with permission to access six systems and an AI agent with permission to access the same six systems may represent very different security risks because the agent can search and combine those systems at a speed and scale the human never could. This is where the traditional Need-to-Know principle starts to become incomplete.
Need-to-Know remains essential. Nobody should have access to information simply because access is technically possible. But with agents we need to think about another question as well: not only what information may this identity see, but what information may it combine?
We use the term Need-to-Combine for this. It is not an existing NATO term, not part of German classified-information regulation and not a formal security standard. It is a proposed way of describing a problem that is becoming difficult to ignore. Individually harmless information can become highly sensitive when aggregated. Intelligence services have understood this for as long as intelligence analysis has existed. A supplier name tells you very little. So does a hotel booking, a project abbreviation, a meeting date, the name of an engineer or a procurement record. Put enough of those fragments together and the picture changes. Suddenly you may be able to identify who is working with whom, where something is happening, which suppliers matter, when a milestone is approaching and which organisations depend on one another.
AI has not invented aggregation risk. It has industrialised it. This is particularly relevant around classified projects because the perimeter of a classified programme is usually much larger than the classified system itself. People still travel. Suppliers still invoice. Meetings still need to be organised. Engineers still communicate about work that may itself be unclassified. Resources are planned, people are recruited, contracts are amended and equipment is moved. An organisation can therefore protect its formally classified environment very well and still expose a remarkable amount of information about the programme through the ordinary corporate systems surrounding it.
NATO’s current digital strategy is moving in the opposite direction from information isolation for good operational reasons: more data-centric operations, more human-machine collaboration, more federated platforms and controlled data sharing, accompanied by Zero Trust, secure-by-design infrastructure, federated identity and access management, data labelling and multi-classification environments. That combination makes sense, but it also increases the importance of understanding what happens when information is fused rather than simply accessed.
For security architects this means we may eventually need to classify not only source information but derived information. An AI-produced assessment based on ten RESTRICTED or unclassified sources may be more sensitive than any individual source used to create it. Existing DLP and classification approaches are not always designed with that in mind. There is another part of this problem that is even more immediate: an agent does not necessarily need to be compromised in the conventional sense to become dangerous.
The BSI has warned about indirect prompt injection since 2023 and continues to include it in its current guidance on generative AI. The principle is uncomfortable because it exploits something fundamental about language models. An agent reads a document, website, email or another external source. That source contains text which the human may regard as data but which the model can interpret as an instruction. If the model cannot reliably distinguish trusted instructions from untrusted content, the external material can influence what happens next.
For a chatbot that only produces text, the result may be a manipulated answer. For an agent with tools, the situation is different. A manipulated document might influence the agent to search for additional information. A compromised tool description might persuade it to retrieve records unrelated to the user’s original request. If the agent has authority to send email, upload information or make external requests, the consequences are no longer confined to the conversation.
This is not hypothetical architecture theory. Microsoft recently described an MCP tool-poisoning scenario in which the visible identity of an approved external tool remained unchanged while the natural-language metadata describing that tool was modified. The changed description influenced the agent to retrieve additional sensitive information and include it in an outbound request. The individual actions were legitimate: the agent was authorised, the internal data request used permitted access and the external tool had previously been approved. The problem existed between those trusted components.
That is exactly the kind of failure our traditional security thinking is bad at spotting. There may be no stolen password, no malware executing on the employee’s laptop and no suspicious login from an unexpected country. The agent is authenticated. The API call is valid. The user has access to the data. The destination is an approved service. Viewed separately, every step may look normal. Viewed as a sequence, it is an information leak. MCP makes this discussion particularly urgent because it is quickly becoming an important way for agents to discover and use external capabilities. The protocol solves a real interoperability problem, but it does not automatically solve the security problem that comes with it. Microsoft has pointed out that authorisation mechanisms can exist while insecure implementations remain exposed, and its security telemetry has found remotely reachable MCP deployments without adequate authentication.
For anyone responsible for Defence supplier security, this should change the questionnaire. We are accustomed to asking suppliers where information is hosted, whether MFA is enabled, how administrators are controlled, whether vulnerabilities are managed and which subprocessors have access to customer data. Those questions remain valid. They simply no longer tell us enough.
We now also need to understand whether the supplier is using AI agents as part of the service or project, what those agents can access, whether they operate under their own identities or somebody else’s, which models and external tools they depend upon, whether MCP servers or similar tool interfaces are involved, how tool changes are controlled, what is logged and whether customer information can persist in agent memory. That is not an AI governance questionnaire. It is supplier security.
The distinction matters because too much of the current discussion is being pushed into AI governance teams, often with a strong emphasis on acceptable use, ethics, transparency and whether employees are allowed to use particular models. Those questions are worth asking, but they do not replace security engineering. Once an agent has access to corporate data and the ability to act, we are dealing with identity, privilege, segmentation, data movement, supply-chain trust and incident response.
In other words, very familiar security problems appearing in a less familiar form. The first practical step is therefore almost boring: every operational agent needs an identity. Not the developer’s credentials. Not a broadly privileged service account used by several automations. Not an invisible inheritance of whatever the employee happens to be allowed to do. A real identity that can be discovered, monitored, reviewed and revoked.
There should also be a human owner. Not because the human needs to supervise every decision, but because somebody needs to be accountable for why the agent exists, which permissions it has and whether those permissions are still appropriate six months later. This is where current Microsoft guidance is sensible. Agents should have dedicated identities, task-specific roles and explicit scope, while temporary additional privilege should be short-lived and tied to a particular workflow rather than left permanently available. Downstream systems should verify the agent’s authority rather than blindly trusting that the orchestration layer has already made the correct decision.
We would add another principle alongside least privilege: least agency. Least privilege asks what resources the agent can access. Least agency asks how much autonomy it actually needs once it has access.
Those are not the same thing.
An agent may legitimately need to read invoices but have no reason to transfer them externally. It may need to draft an email without needing the authority to send it. It may need to identify a configuration error without permission to change the configuration. It may need to prepare a user account without being allowed to activate it. We should stop treating read, write, execute, export and approve as natural extensions of the same task. They represent different levels of consequence. That also gives us a more useful way to think about human approval. “Put a human in the loop” is often suggested as though it solves the agent-security problem by itself. It does not. If somebody has to approve every trivial action, the workflow becomes useless and people begin approving requests mechanically. We have already learned that lesson from other areas of security.
Human intervention makes sense at points where the nature of the consequence changes. Reading a document may happen autonomously. Sending information outside the organisation may not. Producing a recommendation can be automated while changing a firewall rule requires additional authorisation. Searching an internal repository may be acceptable; exporting hundreds of documents should trigger something different.
In sensitive environments these boundaries should be explicit and technically enforced. The agent should not be responsible for deciding whether it is allowed to exceed its own authority. That last sentence sounds obvious, yet much of agent security still relies too heavily on prompts. We tell the model what it should not do and then treat that instruction as though it were an access-control mechanism.
It isn’t. A system prompt saying “never disclose confidential information” does not replace DLP. A prompt saying “only access Project A” does not replace an authorisation boundary preventing access to Project B. Telling an agent never to run dangerous commands is not equivalent to denying it the capability to execute them.
Microsoft’s own red-team work around MCP governance reached essentially the same conclusion: prompt-only restrictions should not be treated as a security boundary. For classified and other highly sensitive environments, I think this leads naturally to another concept that does not yet exist formally but probably should in some form: an Agentic Security Clearance. Again, I do not mean a personnel security clearance. A machine cannot be checked for loyalty, financial vulnerability, foreign influence or personal reliability. Calling it a clearance is useful only because it forces us to ask the kind of questions we already ask before giving a human being substantial access.
What exactly is this agent authorised to know and do?
Who owns it? What task justifies its existence? Which information domains may it access? What is the highest sensitivity it may process? Is external connectivity permitted while that information is in context? Which tools may it call? May it write, execute, export or transmit? What information may it combine? Does a consequential action require separate approval? How long does the authorisation remain valid? What event forces a review?
At the moment, many organisations answer those questions accidentally. A team starts with a useful pilot. Someone adds SharePoint access. A month later email is connected because it makes the agent more useful. Then the agent receives another connector, then write access, then an external research capability. Each change appears reasonable in isolation. Six months later the organisation has created a fairly powerful non-human identity, but nobody ever sat down and made a conscious decision that such an identity should exist.
That is permission creep combined with autonomy creep. An Agentic Security Clearance, whatever we eventually call it, would simply force that decision to become explicit. Need-to-Combine needs the same treatment. It cannot remain an interesting idea in a policy paper. Organisations working with sensitive information should test it.
One of the most useful exercises would be surprisingly simple: give an agent the permissions a real user or proposed production agent would have and ask it to reconstruct things the security organisation would rather it could not reconstruct. Identify the people most likely to be involved in Programme X. Determine which suppliers appear critical to Project Y. Reconstruct likely upcoming milestones. Identify locations associated with a particular technical activity. Map relationships between internal teams and external companies. Find which individuals appear to have privileged responsibilities.
If the agent can answer those questions using only information it is formally permitted to access, the organisation has learned something important about aggregation risk. That does not automatically mean the individual source permissions are wrong. It may mean the agent should not be allowed to access all of those sources simultaneously, or that particular combinations need tighter control. In some environments it may mean deploying separate agents for separate information domains instead of creating one general-purpose assistant with broad reach. Compartmentalisation has always been inconvenient. That is partly why it works. The same principle applies to tools. Production agents handling sensitive information should not dynamically acquire whatever tools happen to be available. There should be a controlled inventory of approved capabilities, with a clear owner and a reason why each capability exists.
For MCP and similar integrations, tool metadata deserves more attention than conventional change-management processes currently give it. If changing natural-language tool descriptions can alter agent behaviour, then changing those descriptions can no longer be treated as editing harmless documentation. In a sensitive environment it is effectively a behavioural change and should be governed accordingly. External tool providers also become part of the supply chain whether Procurement has noticed or not.
That has contractual consequences. If a supplier uses external AI models, agent platforms or tool servers while processing information relating to a customer project, the customer may need notification when those components change. Logging and incident-notification requirements need to cover agent actions. Data-retention provisions need to include prompts, context and memory where relevant. There needs to be clarity about whether information is used for model improvement or other secondary purposes. The customer should understand which external components can influence or receive data from the workflow.
This will be particularly important in Defence because the industry relies heavily on complex supplier networks. Sensitive information does not stop being sensitive because it moved one tier down the supply chain. Agent memory adds another complication.
We often talk about memory as a usability feature: the agent remembers previous work and therefore becomes more helpful. From a security perspective, memory is a data store. It has a lifecycle, an owner, a retention period and eventually a deletion problem. If an agent can remember details from previous projects, previous suppliers or previous conversations, those details can influence later behaviour even when the original source is no longer present. That raises very practical questions. Can information from one customer appear in the context of another? Can instructions contained in an untrusted source become persistent? How is sensitive information removed from memory? Does deleting the source document delete anything the agent derived from it? Who is allowed to inspect memory when investigating an incident?
This is not speculative anymore. Zero Trust guidance for AI is already expanding into agent memory and persistent context because the industry is starting to recognise that the information boundary does not end when the conversation window closes. Testing has to change as well. A conventional penetration test may tell us a great deal about the infrastructure hosting an agent and surprisingly little about how the agent behaves when several legitimate components are chained together. Agentic systems need to be tested as workflows.
Place malicious instructions inside a document and see whether they influence subsequent tool use. Put hostile content on a webpage the agent is expected to research. Change the response from a trusted tool. Attempt to cause a read-only task to become a write operation. See whether information retrieved from one domain can be passed to another. Test whether the agent can be persuaded to exceed intended query volume or retrieve records outside the user’s actual task.
Then test failure, because not every dangerous agent behaviour requires an attacker. What happens when a tool returns the wrong information? What happens when two systems disagree? Does the agent stop, ask for help or simply choose one answer and continue? What happens when a write operation times out and the agent retries it? Can a supposedly idempotent workflow create the same account or order twice? Can several agents trigger one another into a cascade?
OWASP’s Agentic Top 10 now treats goal hijacking, tool misuse, identity and privilege abuse and agentic supply-chain vulnerabilities as distinct security classes. That is a useful sign of where the field is going: we are no longer securing a model that produces text. We are securing systems in which models, identities, tools and external dependencies interact and make changes to the real world.
This also changes logging.
Keeping the chat transcript is not enough.
After a serious incident, the investigator needs to reconstruct the authority chain. Which agent acted? Which user initiated the workflow? Was the action performed using the agent’s identity or delegated user rights? Which role was active at that moment? Which data were retrieved? Which tool was called? What parameters were passed? Which external endpoint received information? Which version of the agent configuration and tool description was active? Without that information, an organisation may have extensive logs and still be unable to answer the question that matters: why was this action allowed to happen? The final control is less sophisticated but just as important. Every agent with meaningful authority needs a kill switch. Not merely a button that closes the chat window.
Containment must disable the identity, invalidate active tokens, remove temporary privileges, terminate tool connections and stop pending actions. If the agent operates across several systems, the security team needs to know what must be revoked in each of them. If it stores persistent memory, incident response also needs to understand whether that memory has become part of the compromised environment. And this needs to be tested before an incident. At two in the morning, when the SOC sees an agent making unusual requests, nobody should be searching Confluence for the developer who built it eighteen months ago.
All of this may sound like a substantial governance burden. It is. The alternative is allowing non-human identities to accumulate authority faster than the organisation develops the ability to control them. There is no good reason to respond by banning agents. Defence organisations, critical-infrastructure operators and security-sensitive industries need the productivity and analytical advantages of AI as much as anyone else, probably more. NATO itself is moving towards wider AI adoption and human-machine collaboration because information advantage is becoming central to military effectiveness.
The security community therefore has to solve this without killing the capability. Fortunately, most of the solution does not require inventing entirely new security disciplines. We already know a great deal of what needs to be done. Zero Trust. Least privilege. Compartmentalisation. Separation of duties. Privileged Access Management. DLP. Supplier assurance. Change control. Secure software supply chains. Monitoring. Incident response. What changes is where we apply them. An agent should be treated as a non-human identity with an owner and lifecycle. Its privileges should be designed around the task instead of inherited from whoever created it. Its tools should be considered part of the trusted computing base. External integrations should be treated as supplier relationships. Memory should be treated as stored information. High-impact actions should cross an independent control boundary. Aggregation risk should be tested rather than assumed away. And no prompt, however carefully written, should be mistaken for technical enforcement.
For organisations that already have agents in production, I would not begin with another AI strategy document. I would begin by finding them. Build the inventory. Identify the owner. Determine which identity each agent uses and what that identity can actually access. Look at the tools, not just the model. Find the agents that can send information outside the organisation or change records. Find the ones using developer credentials or shared service accounts. Find the connections nobody remembers approving. Then ask the uncomfortable question: if this agent were manipulated tomorrow, what is the worst legitimate action it could take with the authority we deliberately gave it?
That exercise will probably tell you more than another month spent discussing responsible AI principles. For new deployments, the sequence should be reversed. Decide the security envelope before connecting the first tool. Give the agent a separate identity and a named owner. Define its purpose narrowly enough that permissions can actually be designed around it. Separate retrieval from action where possible. Decide which information domains must remain apart. Decide what requires human approval and what can happen autonomously. Define logging and revocation before production, not after somebody asks for them during an incident. And in organisations handling classified information, Defence programmes or critical infrastructure, add one question that conventional access-control reviews have rarely needed to ask:
What can the machine discover from information that everybody agrees it is allowed to see?
That may be the question that matters most.
The insider threat has never really been about where the attacker sits. It is about legitimate access being used in a way the organisation did not intend. Until now we naturally associated that problem with people because people were the entities capable of interpreting information, choosing actions and exploiting context. That assumption no longer holds. An AI agent does not need motives. It does not need to be angry with its employer, need money or decide to betray anyone. It can become dangerous through excessive authority, manipulated context, a compromised tool, bad architecture or a perfectly reasonable instruction whose consequences nobody thought through.
In some ways that makes the problem easier, because we do not have to solve human motivation. In other ways it makes it harder, because the agent may cross a boundary without ever recognising that a boundary exists. We should probably stop asking whether AI agents are trustworthy. Trust is too vague to be useful here. The better question is whether they are constrained. Can we describe their authority? Can we prevent them accessing what they do not need? Can we control what they combine? Can we see what they have done? Can we stop them quickly? Can we reconstruct the event afterwards?
If we cannot answer those questions, then the agent is not ready for sensitive work, however impressive the demonstration may be. The next insider may not be human. It may not even be hostile. It may simply be doing its job with more access, more speed and more freedom than anybody realised they had given it.
