Who Authorized the AI to Commit the Company

An AI agent with legitimate access to a system takes an action that commits the organization to something. A discount offered, a term accepted, a purchase made, a commitment stated to a customer. Access control governed whether it could reach the system, and says nothing about whether it had standing to do that.

‍

Lawyers have covered whether such an action binds the company, and the answer is broadly yes. What has not been written is what a governance function should record so the question is answerable afterward, which is a different problem and the one a security team can act on.

‍

Why Doesn't Technical Access Determine Authority?

‍

Because authority is conferred by the organization's conduct rather than by its configuration, and the two can point in opposite directions.

‍

Agency principles treat an AI system as an instrument of the organization deploying it rather than as a party in its own right, so the organization carries the consequence. Authority conferred explicitly, through stated limits and system constraints, is one route. Authority a counterparty reasonably infers from how the organization presented the system is another, and the second does not depend on any internal permission having been granted.

‍

The Usual Security Reasoning Inverts

‍

A security function reasons about what an agent can technically do and constrains that. Apparent authority turns on what somebody outside reasonably believed it could do, which is a function of how the system was presented rather than of what it was permitted. A hard limit in the code is a real control and it does not resolve a dispute where the interface implied something wider.

‍

What Does an Approval Workflow Record?

‍

Only that somebody clicked, which is a weaker statement than it appears and the reason approval trails do not answer this question.

‍

A deployment record naming an approver establishes that a person authorized the deployment. It does not establish that the person held authority to confer commercial commitment powers on a system, which is a separate question about their own delegated limits. An engineering manager approving an agent that can accept contractual terms has approved something outside their own authority, and the record shows an approval either way.

‍

Which Field Is Missing?

‍

The approver's own limit. An agent cannot hold authority exceeding the person whose authority it acts under, so the useful record states what that person was themselves permitted to commit. Almost no deployment record contains it, and the approval gate before deployment is where it would have to be captured.

‍

What Would a Delegation Record Contain?

‍

Five fields, none of which appears in a typical agent inventory.

‍

• Whose authority it acts under: A named individual rather than a team, since delegated authority descends from a person.
• The approver's own limit: What they are permitted to commit, since the agent cannot exceed it.
• The agent's stated limits: Value, type and counterparty, expressed as constraints rather than as instructions.

‍

Presentation and revocation complete it. What the agent is held out as able to do, since that is what a counterparty relies on, and who can withdraw the authority together with how quickly. The fourth field is the one no security inventory contains, because presentation is a marketing and product decision rather than a technical one.

‍

Which Controls Reduce This Exposure?

‍

Two sets, and most organizations have only built the first.

‍

Permission controls bound what the agent can execute. A value ceiling enforced in the transaction path, a restricted set of actions, a requirement for confirmation on anything irreversible. Those are the familiar ones and they are worth having.

‍

Presentation controls bound what a counterparty can reasonably infer. Disclosure that the system is AI rather than a person, stated limits visible at the point of interaction, and explicit statements about what the system cannot agree to. Those sit with product and communications rather than with security, which is why they are frequently absent.

‍

Where Do Those Two Overlap With Regulation?

‍

Usefully, and it is worth noticing because the compliance work is already being done. Transparency obligations requiring disclosure that a person is interacting with an AI system are in force in Europe, and that disclosure requirement also happens to be the strongest defense against an inference of wider authority. A control built for one purpose serves the other.

‍

Which Agents Carry This Exposure?

‍

A narrower set than the full population, which makes the record achievable rather than theoretical.

‍

Three properties define it. The agent interacts with somebody outside the organization, since internal actions cannot create third-party reliance. It can take an action with commercial or legal effect rather than only retrieving information. Its output also reaches the counterparty directly rather than through a person who reviews it.

‍

Why Does the Third Property Matter Most?

‍

Because a human between the agent and the counterparty changes who committed. Where a person reads the agent's output and sends it, the person committed and the agent assisted, which is the ordinary situation and carries no novel exposure, and whether a review step is genuine decides which case applies. Removing that step is what moves the commitment to the system, and whether the review is doing anything determines whether the step is real or nominal.

‍

How Should the Exposure Be Sized?

‍

Size it by the commitments the agent can make rather than by the data it can reach, which is a different calculation from the usual one.

‍

An agent able to offer a discount carries exposure equal to the discount multiplied by how many times it could be offered before somebody noticed. One able to accept contractual terms carries the cost of performing those terms or of disputing them. Neither figure appears in a data-oriented risk assessment, and both are estimable from the action set. AI risk quantification, or AIRQ, priced on the action set rather than on the data reached is what surfaces it.

‍

What Bounds the Multiplier?

‍

Detection time, as with any agent exposure. An agent making an unauthorized commitment once is a dispute, and one making it four hundred times before anyone looked is a different order of problem. Rate limits on commercially consequential actions therefore do more for this exposure than tightening the value ceiling.

‍

What Happens After an Unauthorized Commitment?

‍

A dispute in which the organization argues the agent lacked authority, and the strength of that argument depends on records made before the event rather than after.

‍

Three things help. Evidence that limits were stated where the counterparty could see them, since apparent authority turns on what they could reasonably infer. Evidence that the system was disclosed as AI rather than presented as a person. Then a delegation record showing the authority the agent held and from whom, which establishes that internal limits existed rather than being asserted retrospectively.

‍

Which of Those Cannot Be Created Later?

‍

All three, which is the point. An interface screenshot taken during a dispute shows the interface during the dispute. Stated limits added after the event are evidence of a change rather than of what applied at the time. An AI data fabric that records what each agent could do, and when that changed, supplies the dated version, and change records that survive scrutiny is the general form of the requirement.

‍

Who Should Hold the Record?

‍

Whoever owns the agent inventory, with legal able to read it, since the record is only useful if counsel can find it under time pressure. A delegation record held by an engineering team and unknown to legal is a record that will not be produced when it matters.

‍

What Should Be Established First?

‍

Three questions, and the first usually produces a short list.

‍

Which agents interact with parties outside the organization and can take an action with commercial effect. For each, whose authority it acts under and what that person is themselves permitted to commit. Then what the agent is presented as being able to do, which requires reading the interface rather than the configuration. An AI Interaction Data Fabric establishes the first two from observed activity, and the third is a conversation with whoever owns the product surface.

‍

Record the Delegation, Not Just the Approval

‍

Access control decides what an agent can reach and authority decides whether it had standing to act, and the two are set by different mechanisms. Authority a counterparty reasonably infers from how the organization presented a system does not depend on any internal permission, so a hard limit in the code is a real control that does not settle a dispute. Approval workflows record that somebody clicked rather than that they held authority to confer commitment powers, and the missing field is the approver's own limit. The controls that help sit partly with product rather than with security, and the disclosure obligations already in force serve both purposes. Kovrr's AI Security and Governance Platform records whose authority each agent acts under, which is the field the rest depends on.

‍

To see which agents in your environment act under whose authority and what each can commit, book a demo mapped to your own estate.