When most people connect an AI tool to an account, the mental model is still fairly simple: the software can now access something it could not access before.

It can read email. It can use a calendar. It can retrieve files. It can call an API.

That model works reasonably well when the software is waiting for a human to tell it exactly what to do.

It becomes much less useful when the software is an agent.

An agent may be given a goal instead of a single instruction. It may decide which tools are relevant, perform several steps, request assistance from another agent, return later when a condition changes, or initiate an action without the business owner personally approving that exact action at that exact moment.

At that point, the important question is no longer simply:

What can this agent access?

It is:

Who gave this agent permission to make this particular thing happen?

Those are not the same question.

Access and authority are related, but they are not identical.

Imagine your Executive Agent can access your company email.

That tells us something about capability.

It does not tell us whether the Executive Agent is authorized to send a contract acceptance, cancel a vendor relationship, negotiate pricing, promise a customer a refund, change the terms of a partnership, or delete three years of correspondence.

The system may technically allow all of those actions through the same account.

Your business rules may allow only some of them.

That distinction between technical capability and business authority is going to become one of the most important distinctions in agentic companies.

Microsoft's current Agent ID architecture already reflects part of this problem. Agents can receive delegated permissions when they are acting on behalf of a user, or application permissions that allow app-only access when an administrator has authorized it. Microsoft also blocks certain particularly powerful permissions from being granted to agents at all, including broad permissions that could allow control over users, applications, roles, or directories.

That is identity infrastructure saying something important:

Being able to authenticate an agent does not mean giving it unlimited authority.

For a one-human company, the same principle needs to exist at the business level.

Your Executive Agent may need enough access to coordinate the company without automatically inheriting every decision the owner herself could make.

“I connected it to my account” is not an authorization strategy.

This may become one of those sentences that sounds obvious in hindsight.

Right now, many AI integrations still begin with a familiar consent flow. The user signs in, sees a list of requested permissions, and approves or denies them. Microsoft's current agent sign-in process explicitly describes this as allowing an agent to join the organization and then requesting access to particular data or actions.

That is useful.

But account-level permission is still a fairly blunt instrument compared with the way businesses actually make decisions.

A business owner may be perfectly comfortable allowing an Executive Agent to read every incoming vendor email while requiring human approval before it agrees to a price increase.

The same owner may allow an advertising agent to spend up to $300 without approval, require confirmation between $300 and $1,000, and prohibit anything above $1,000 entirely.

A publishing agent may be allowed to schedule approved articles but prohibited from changing an article's claims, deleting published material, or responding to a legal complaint.

A customer-service agent may issue refunds under $50 while escalating larger disputes.

These are not merely access permissions.

They are authority boundaries.

The agent needs to know not only what door it can open, but what it is authorized to do after walking through it.

The Executive Agent makes this more complicated because authority can travel.

In the one-human company we have been building throughout this series, the owner does not necessarily communicate individually with every specialized agent.

The owner may tell the Executive Agent:

“Prepare next week's launch.”

The Executive Agent then determines that the task requires research, writing, design, inventory confirmation, customer messaging, advertising preparation, and perhaps a purchase.

Several agents become involved.

Now imagine the advertising agent spends money.

Where did its authority come from?

The advertising agent may say, in effect:

The Executive Agent told me to do it.

The Executive Agent may say:

The owner authorized me to prepare the launch.

The owner may say:

I authorized preparation. I did not authorize a $4,000 ad buy.

There is the problem.

The action may have passed through several technically legitimate steps while the meaning of the original authorization changed along the way.

That is why delegation needs more than a chain of commands.

It needs a chain of authority.

A useful authority chain needs to preserve limits.

A healthy version might look something like this conceptually:

The owner authorizes the business to pursue a particular objective. The Executive Agent receives defined authority to coordinate that objective. The Executive Agent delegates specific portions of the work to specialized agents. Each specialized agent receives only the capabilities necessary for its assigned portion, and every delegation preserves the limits imposed higher in the chain.

If the human has authorized a maximum spend of $500, the Executive Agent should not be able to create three subordinate agents with $500 authority each and accidentally transform a $500 limit into $1,500 of spending power.

If the human requires approval before publication, delegating the drafting work should not quietly turn into delegated publishing authority.

If the Executive Agent can read confidential legal documents, that does not mean every temporary research agent it creates should inherit those documents automatically.

This sounds like a technical security problem because part of it is.

It is also a basic organizational problem.

Companies already understand this when humans are involved. A department manager may be authorized to approve certain expenses without being authorized to sell company property. An employee may have access to payroll software without having authority to change executive compensation. A contractor may receive the information necessary to complete an assignment without receiving the company's entire internal archive.

Agentic companies need the same conceptual discipline.

The difference is that delegation may happen much faster and at much greater scale.

We are already seeing infrastructure for inherited agent permissions.

Microsoft now supports inheritable permissions for agent identities. Permissions can be preauthorized at the blueprint level so newly created agent identities can inherit approved capabilities rather than forcing each new agent through an entirely separate authorization process.

That is useful for organizations creating many agents with similar functions.

It also gives us a glimpse of the governance problem ahead.

Inheritance makes agent creation easier.

Inheritance can also make authority easier to reproduce.

For a large enterprise, identity administrators may manage that architecture.

For a one-human company using an Executive Agent that can create or coordinate specialist agents, the question becomes more immediate:

What does a child agent inherit merely because its parent was trusted?

That needs an explicit answer.

A trusted Executive Agent should not necessarily produce trusted descendants with identical authority.

Otherwise permission becomes hereditary.

And hereditary authority is a hell of a thing to introduce into software accidentally.

This is why the authority graph may matter more than the org chart.

Traditional organizational charts tell us who reports to whom.

An agentic company needs something else alongside that.

It needs to show which entity derives authority from which other entity, what kind of authority was delegated, what limitations remain attached to it, and whether that authority can be delegated again.

For our one-human company, the organizational structure might look straightforward.

There is one owner. Beneath the owner sits the Executive Agent. Beneath the Executive Agent sit several specialist agents.

The authority structure may be much more complicated.

The Executive Agent might be allowed to instruct the research agent but prohibited from changing its data-access permissions. The finance agent might be allowed to prepare payments but not release them. The commerce agent might be permitted to purchase from a preapproved vendor list but unable to establish a new vendor relationship without human approval.

The same agent can therefore be subordinate in one sense while holding significant independent authority in another.

That is why thinking only in terms of “boss agent” and “worker agents” will eventually become inadequate.

The important thing is not merely who reports upward.

It is where permission came from and where it is allowed to go next.

NIST is asking essentially the same question.

In 2026, NIST's National Cybersecurity Center of Excellence began formal work around software and AI-agent identity and authorization. Its stated concerns include identification, authorization, auditing, non-repudiation, and the challenges created when agents receive access to multiple tools, applications, and data sources.

This matters because identity alone cannot solve the problem.

Knowing that Agent 47 performed the action is valuable.

The next question is still:

Was Agent 47 authorized to perform it?

Then:

Who granted that authorization?

Then:

Was the person or agent granting it authorized to do that?

Then:

Was the authority still valid when the action occurred?

This is how what looks like a simple permission setting becomes a provenance problem.

We need provenance not only for content.

We increasingly need provenance for authority.

Delegation may eventually need a receipt.

There is emerging technical work moving in exactly this direction.

One 2026 Internet-Draft proposes an Agent Identity Protocol built around decentralized identifiers, capability-based authorization, and cryptographically verifiable delegation chains for multi-agent systems. It is important not to treat that proposal as an adopted standard; Internet-Drafts are works in progress. But the problem it is trying to solve is revealing: when autonomous agents delegate capabilities to one another, a receiving system needs a reliable way to determine where that authority originated and whether the delegation is valid.

In plain language, the future agent may need to arrive with something resembling:

I am Agent B. Agent A authorized me to perform Action X. Agent A received that authority from Business Y. The authorization is valid until Date Z. I am not permitted to delegate it again.

That is far more useful than:

Trust me, my boss sent me.

Humans have spent centuries creating signatures, corporate resolutions, powers of attorney, purchase orders, licenses, certificates, job roles, and contractual authority because organizations cannot function on “somebody told me it was fine.”

Agents are unlikely to eliminate that need.

They may force us to make it machine-readable.

The one-human company has a special version of this problem.

Large organizations can separate responsibility.

Security teams govern identity.

Finance teams establish spending limits.

Legal departments determine contracting authority.

Managers approve exceptions.

Auditors review actions later.

The one-human company may have exactly one person sitting above the entire system.

That creates enormous leverage, but also a concentration problem.

If the Executive Agent interprets one vague instruction broadly, there may not be another human layer available to catch the misunderstanding before specialized agents begin acting on it.

The owner therefore needs something more precise than constant supervision.

She needs bounded delegation.

The system should allow the human to define what the Executive Agent can decide independently, what it may delegate, what requires confirmation, what cannot be delegated at all, and which events automatically return control to the human.

That makes the business less dependent on the owner watching everything.

The goal is not human approval for every step.

If that were required, much of the point of autonomous agents would disappear.

The goal is to put the human at the places where human authority actually matters.

Some decisions should probably remain deliberately difficult to delegate.

Different businesses will draw these boundaries differently, but the broader principle is worth establishing.

The more difficult an action is to reverse, the more carefully its authority should be delegated.

Publishing a draft can be reversed relatively easily.

Sending confidential information to an unauthorized third party cannot necessarily be undone.

Preparing a payment is different from releasing one.

Drafting a contract is different from accepting it.

Recommending a new vendor is different from binding the business to a multi-year agreement.

Creating another agent is different from giving that new agent authority to spend money.

The important distinction is not simply “high risk” versus “low risk.”

It is the relationship between autonomy and reversibility.

The less reversible an action becomes, the stronger the case for tighter authorization, clearer logging, or human approval before execution.

That is a governance decision.

Not a prompt-engineering trick.

And “permission granted” cannot mean “permission forever.”

Authority also needs a lifecycle.

An agent may legitimately need access today and no longer need it six months from now.

An agent created for a specific project may retain capabilities long after the project ends.

The Executive Agent may change roles. Vendors may change. Business priorities may change. An agent may be replaced while its old credentials remain valid.

Microsoft's current Agent ID model explicitly treats lifecycle and access review as governance responsibilities. Sponsors are responsible for determining whether agents remain necessary, reviewing access, and participating in decisions about renewal, suspension, or removal. Microsoft has also added lifecycle workflows designed to prevent agents from becoming orphaned when a human sponsor changes roles or leaves an organization.

That is enterprise infrastructure today.

The underlying principle applies just as strongly to a one-human company:

Authority should expire when the reason for granting it expires.

Otherwise the business slowly accumulates invisible permissions.

Humans are very good at doing that with old apps already.

Agents could make the consequences much more interesting.

Revocation is part of authorization, not an afterthought.

Before granting authority to an agent, the owner should know how that authority can be removed.

Microsoft currently allows owners and sponsors to disable agent identities, preventing them from continuing to obtain authentication tokens for protected resources.

That answers one part of the problem.

It does not answer all of it.

If an Executive Agent has already delegated tasks, created subordinate agents, initiated purchases, scheduled publications, issued instructions to external systems, or entered workflows that continue independently, disabling the Executive Agent may stop future authentication without necessarily stopping everything it already set in motion.

That means revocation eventually needs to propagate through the authority chain.

If the root authorization disappears, what happens to authority derived from it?

Does every downstream agent immediately lose permission?

Does work already underway finish?

Are pending transactions cancelled?

Do external agents receive notice that the authorization is no longer valid?

Can the business prove exactly when the authority ended?

Those are difficult questions.

They are also predictable questions.

Which means businesses should not wait until something goes wrong to discover that “disable agent” and “stop everything this agent caused” are two different commands.

The human remains the source of judgment even when the human is no longer the source of every action.

That may be the balance the one-human company needs to preserve.

The point of an Executive Agent is not to require the owner to micromanage every specialist agent underneath it.

The point is to allow operational authority to travel farther without losing the owner's intent along the way.

That requires explicit boundaries.

It requires identity.

It requires a record of delegation.

It requires expiration.

It requires revocation.

And increasingly, it requires knowing whether an agent that grants authority to another agent had the right to grant it in the first place.

The company is no longer merely managing access to software.

It is managing chains of authority between operational entities.

That is a much more significant change.

Because once an Executive Agent becomes central enough to coordinate the company, hold permissions, delegate work, and maintain relationships across the business, the owner eventually has to ask another question:

If I gave this agent authority, can I truly take all of it back?

That is where we go next.