Your AI Agent Needs an Authority Matrix, Not Just an API Key

A lot of the AI conversation is still framed around access. What systems can the agent connect to? What data can it read? What tools can it call? What APIs can it use?

Those questions matter, but they are not enough. Once software can take action, access starts to look more like delegated authority. The important question is no longer only what an agent can reach. It is what the agent is actually allowed to decide and do without a human approving the action.

That distinction will matter more as agents move deeper into company operations. An agent that summarizes support emails is doing one kind of work. An agent that drafts responses is doing another. An agent that sends those responses to customers, updates account records, promises refunds, triggers workflows, or modifies code is in a different category. Those permissions should not collapse into one another just because the technical integration makes each step possible.

Access is not authority

Companies already understand this with people. A finance employee may have access to the accounting system without authority to approve every payment. A sales employee may be able to view a contract without authority to accept unusual terms. A manager may approve certain expenses but not others. A founder may delegate customer communications without delegating pricing exceptions, settlement authority, or bank permissions.

That is ordinary operating discipline. Agentic software creates a reason to apply the same discipline to non-human actors.

The issue is not that every AI deployment needs a giant governance process. The issue is that founders should be clear about the difference between technical capability and business permission. If an agent can read email, update Salesforce, send Slack messages, open support tickets, prepare invoices, issue credits, schedule meetings, or interact with vendors, the company should understand which of those actions are merely possible and which are actually authorized.

An API key can answer the first question. It cannot answer the second.

The authority matrix

The useful tool is an authority matrix. That sounds more formal than it needs to be. At its core, it is a simple map of what the agent may access, what it may do, what requires approval, and what is off limits.

For many startups, the first version can be a basic table: system, data, permitted actions, autonomous actions, approval-required actions, approver, logging, and revocation. The value is not the format. The value is that the company is forced to make the decision before the workflow becomes part of daily operations.

Can the agent read customer messages? Can it draft replies? Can it send them? Can it make promises about refunds, credits, timelines, product behavior, or contract terms? Can it update the CRM? Can it change a billing record? Can it modify code? Can it merge code? Can it contact a vendor? Can it trigger a workflow that affects a customer?

Different answers may be reasonable for different companies. The point is to make the answers explicit.

Scope creep is the real problem

The practical risk is usually not a dramatic scenario where a company intentionally gives an agent broad control over the business. It is quieter than that.

A team starts with a narrow use case. The agent reads a knowledge base and summarizes customer issues. That works, so the team lets it draft responses. Then it gets connected to the support platform. Then it starts tagging accounts. Then it updates the CRM. Then someone connects it to billing, product analytics, or code because that makes the workflow faster.

Each step may make sense in isolation. The combined authority may be broader than anyone approved as a whole.

That is what an authority matrix is meant to catch. It forces the company to look at the workflow end to end instead of treating each integration as a separate technical decision. An agent with access to email, files, customer records, code, and internal chat may not look dangerous at any single point. But the combined permissions may allow it to gather information, make decisions, and take actions in ways the company never really reviewed.

That is not only a cybersecurity issue. It is an operating issue.

Approval has to match the action

A lot of AI products and internal deployments use some version of "human in the loop." The phrase can be useful, but it can also obscure the question that matters: what exactly is the human approving?

A person can approve a draft, a recommendation, an external communication, a transaction, or a system change. Those are different approvals. If the person reviewing an agent's output thinks they are approving a summary, but the workflow treats that approval as permission to send a customer-facing message, the company has a design problem.

The approval step should be tied to the action that matters. For low-risk work, that may be light. For higher-impact work, the approval should be clearer. Sending external communications, changing records, making financial decisions, deleting data, modifying code, or taking actions that affect customers should not be treated the same as summarizing information for internal review.

The company can choose where it wants autonomy. It should not stumble into it.

Logs are part of the control

If an agent acts, the company should be able to reconstruct what happened. That does not mean every startup needs enterprise-grade compliance infrastructure on day one, but it should be able to answer basic questions: what did the agent do, what system did it touch, what data did it use, was the action autonomous or approved, who approved it, what changed, and can it be reversed?

Those questions matter when something goes wrong. They also matter when things go right, because logs help founders see whether the agent is actually improving the workflow or quietly creating new operational risk.

An authority matrix without logging is incomplete. The matrix says what should happen. The logs help show what did happen.

The founder-level issue

It is tempting to treat this as a security team problem. Security matters. Identity, least privilege, tool access, audit trails, revocation, and monitoring all matter. But founders should not outsource the whole issue to technical controls.

The deeper question is commercial and organizational. What decisions can the company delegate? Which actions need judgment? What should stay with a person? What needs escalation? What risk is acceptable for speed? What kind of mistake would be annoying, and what kind would be expensive?

Those are business questions. They are also the same kinds of questions companies already ask when delegating authority to employees, officers, managers, contractors, vendors, and service providers. Agents do not eliminate that discipline. They make it easier to forget.

Founders do not need to make this mystical. Start with the agents that touch customers, money, contracts, code, sensitive data, or external systems. Map what they can read, what they can draft, what they can change, what they can send, what they can approve, what requires review, and what is off limits.

Technical capability should not silently become organizational authority.

An agent does not need broad authority just because it can call the tool. The company should decide what the agent is allowed to do, document that decision, and keep enough of a record to know whether the agent stayed inside the lines.

That is not bureaucracy. It is basic operating control for software that has started to act like part of the company.