ArticlesModels as Insiders: Whose Authority, and Whose Data

An employee asks an agent for a report. The agent reads a client list and sends a copy outside the organization. The log identifies the agent, and the employee who started the task.

That record establishes neither that the employee asked for the transfer nor that the organization authorized it. The agent may have exceeded the request. Its permissions may have exceeded the task. An instruction encountered during execution may have redirected it. These are different explanations, with different consequences for the case, and the agent’s identity settles none of them.

On 10 October Satya Nadella published an essay proposing that frontier models, closed and open-weight, be treated as insider risks. His governing principle is to separate the supply of intelligence from the authority over it, with the controls on access and action outside the model. He draws on established enterprise security practice, and he keeps responsibility with the organization. Seven design principles follow, from model diversity to incident disclosure.

I work in insider risk, and the position I have taken here is the one the essay rests on: an agent with its own identity is an insider, because an insider is defined by access, and agents execute while people command, so the authority over what an agent does always sits with someone else. Applying it to the client-list case raises two questions: on whose authority did the agent act, and whose personal data is needed to establish the answer?

The principles, and the program’s measures#

Nadella’s principles correspond to measures used in insider risk programs: independent review, evidence preservation, effectiveness testing, access controls, validation, containment, and reporting. These are correspondences, not equivalences.

I would bring the agent into the program’s asset scenarios and its case procedure, under a mandate and with named decision owners. Identity management establishes access; incident response contains incidents; the insider risk procedure investigates how authorized access was used and whether the action served its permitted purpose, and it names the function that decides the consequences, corrective or employment measures included. The client list shows what that procedure has to separate.

Access, authority, and purpose#

A case concerning a person has to distinguish what they did, what they were authorized to do, and what responsibility follows. The confirmation criterion, the interview, and the consequence framework depend on those findings. An agent may act within the authority delegated to it, exceed it, or act after it has been compromised, and an execution log alone may not establish which. In the client-list case I would separate three questions.

A successful permissions check answers only the first question. A prompt is evidence of a request, and the person who wrote it may lack the authority to authorize every action it contains. An approval is read against the authority of the person who gave it. And the three findings leave a fourth question open: what harm occurred, and what caused it. An action can be authorized, serve its permitted purpose, and still produce a harmful result; authorization does not establish that the controls or the outcome were adequate.

The delegation record#

The organization assigns responsibilities; the program records them and tests them against the facts of the case. It does not acquire authority over deployment, access, or employment decisions by opening one.

For each agent, I would record the deploying owner, the standing mandate, the permissions granted, and every change to them. For each task, I would retain the evidence that connects the request to the action: the identity that started it, the scope of the request, any approval given along the way, and the permissions and configuration in force during execution, because the authority exercised may differ from task to task. A change must remain distinguishable from the state it replaced. Where one agent delegates work to another, the record keeps that relationship and the scope passed on. The first agent’s identity does not establish what the second was asked or permitted to do. The second agent’s account of its task is tested against the evidence of the systems that granted the access and recorded the execution.

A recorded principal identifies the delegation. It does not establish that the principal authorized the disputed action, nor that it was the principal’s misconduct; those are findings of the case, as they are for a person. Where the evidence cannot establish authorization, the finding is recorded as unresolved, with the evidence that is missing. A gap in the delegation record is a control deficiency to resolve. It is not, by itself, proof that the employee authorized the transfer, nor that the agent acted without authorization; other evidence may settle the question. At closure, the case states what was technically permitted, what was authorized, whether the permitted purpose was respected, what harm occurred, and what remains unknown. Each corrective or employment measure goes to the decision owner named in the mandate.

Whose data#

The delegation record creates a collection requirement, and with it a limit: the program has to justify the personal data it collects to reach those findings.

A model has no employment rights. The safeguards built for people, proportionality, purpose limitation, the information notice, the agreement with the workers’ representatives where the jurisdiction provides for it, do not protect the model. They protect the people in its records. An assistant that reads an employee’s mailbox and drafts in their name produces records about that employee and about the people they write to. An agent the organization runs on its own identity produces records that can still reveal what a named person asked it to do. Observing an agent is therefore not exempt from the regime that governs observing people.

In the European Union and the European Economic Area, the General Data Protection Regulation applies to the personal data in the agent’s records regardless of who executed the action. National employment law adds its conditions. In Germany, where a works council exists, a technical system able to monitor employee conduct engages co-determination, and a conciliation award can replace an agreement. A data protection impact assessment is due before the processing starts where it is likely to pose a high risk, as systematic monitoring of employees usually is and as the supervisory authorities’ lists often state, with the advice of the Data Protection Officer where one is designated.

For each type of record collected, I would specify the purpose and lawful basis, the necessary fields, who may read it, and the retention period, and I would define them for each scenario before collection is enabled. The record has to be sufficient to test a delegation without making the full contents of a mailbox, or every document opened, the default collection; where content is necessary, that necessity has its own assessment. The same assessment applies to an agent the organization owns and one employee prompts every day: ownership and identity do not decide whose personal data the record contains. Assuming that an account may be compromised is a design premise, not an accusation of its holder; the mandate distinguishes technical containment from employment measures, and names who may authorize each.

Before the first case#

Before an agent enters the scope, I would ask the program to show that it can reconstruct a disputed delegation from records collected under defined purposes and safeguards. A controlled test can use the client list: a request for a report, permission to read, a disputed transfer, and a change of approval or permissions during the task. The test shows which findings the evidence supports, and where the procedure has to leave a question unresolved.

This is what I would bring through insider risk: a case procedure that distinguishes access, authority, and purpose, records what remains unresolved, and justifies the personal data needed to reach its findings.