Who Owns the AI Agent? Assigning Accountability Before Something Goes Wrong

Written by Connor Fitzgerald

Key takeaways

• Most organizations can describe what their AI agents do, but few can name the one person accountable for them.

• “The vendor built it” or “the AI did it” doesn’t hold up. In Moffatt v. Air Canada, a tribunal rejected the argument that a chatbot was responsible for its own actions.

• NIST and OWASP both point to documented roles, scoped permissions and executive responsibility. Neither names a single owner for you.

• Assign one accountable owner per agent, backed by defined support roles, and write the vendor’s obligations into the contract.

• You can do the core work in about 30 days.

Ask three people in your company who owns the AI agent that handles customer emails, drafts contracts, or moves data between systems. You’ll likely get three answers: the team that built it, the vendor that sold it, and “IT, I think.”

That gap is the real AI agent ownership problem. Ownership means one named person is accountable for what an agent can access, what it can spend, and what it’s allowed to do. Most deployments don’t have it. They were rolled out quickly, often through a service provider, and nobody was assigned to answer when something went wrong.

This post covers why that matters, what the frameworks say, how organizations typically assign ownership, and what to ask your technology providers before you sign.

Why AI agent ownership gets skipped

Agents are easy to start and hard to place on an org chart. A pilot begins in one department, uses a shared credential, and expands because it works. By the time it touches email, files or customer data, it has no budget line, no access review, and no offboarding plan.

A recent CYBR.SEC.Media piece on AI spend as a security control made a related point. A valid credential making valid requests looks the same whether the person behind it is working normally or misusing it. It also noted that when an incident hits, the board wants to know who was supposed to be watching, whether or not that team stood up the tool.

If you buy AI services rather than build them, the gap is wider. The provider runs the platform, your team configures it, and the business uses it. Responsibility ends up spread across all three, which usually means nobody holds it.

“The AI did it” is not a defense

In Moffatt v. Air Canada (2024), a British Columbia tribunal heard a customer’s claim over wrong information from an airline chatbot. Air Canada argued, in effect, that the chatbot was a separate entity responsible for its own actions. The tribunal rejected that, finding the chatbot was part of the airline’s website and the airline was responsible for what it said (McCarthy Tétrault summary, American Bar Association analysis).

This was a small-claims tribunal in one Canadian province, so it isn’t binding elsewhere, and it concerned a chatbot rather than an autonomous agent. The principle still applies. A customer, regulator or court will look at the organization that deployed the system, not at the software. Speak with qualified legal counsel about how liability applies to your situation.

What the frameworks say about accountability

Two widely used references point the same way.

NIST AI RMF. The NIST AI Risk Management Framework (AI RMF 1.0, NIST AI 100-1) is voluntary guidance organized around four functions: Govern, Map, Measure and Manage. The Govern function covers accountability structures, including documented roles and responsibilities, training, and executive leadership taking responsibility for AI risk decisions. NIST also publishes a Generative AI Profile (AI 600-1) as a companion.

OWASP. The OWASP Top 10 for Agentic Applications 2026 covers ten risk categories for systems that plan, remember, call tools and act with delegated authority. Its risks include tool misuse and identity and privilege abuse. OWASP’s GenAI Security Project also released an updated LLM Top 10 for 2026, and recommends using the two lists together when a model has tools and permissions.

Neither framework tells you which person to name. They tell you that someone must be named, roles must be written down, and permissions must match the task. You still have to make that call.

Four ways organizations assign AI agent ownership

Option 1: IT owns it

IT already manages platforms, credentials and integrations, so this feels natural. The weakness is that IT rarely owns the business outcome. It can keep the agent running without knowing whether the agent should be doing what it’s doing.

Option 2: The business unit owns it

The team that benefits knows the purpose and the risk of a bad output. It usually lacks the skills to manage credentials, logging and incident response, and it’s the group most likely to expand scope informally.

Option 3: Security owns it

Security can monitor and respond, but owning the agent means owning its purpose and budget, which security typically doesn’t hold. It also becomes the default blame target without the authority to change the deployment.

Option 4 (our recommendation): one accountable owner, with defined support roles

Name one business-side owner per agent who is accountable for purpose, scope and spend. Then assign the rest explicitly:

Role	Accountable for
Business owner (one named person)	Purpose, outcomes, approving scope changes, budget
IT / platform	Deployment, credentials, integrations, offboarding
Security	Monitoring, access reviews, incident response
Finance	Spend caps, anomaly alerts, invoice review
Legal / compliance	Contract terms, regulatory exposure
Provider	Service levels, logging, breach and incident notification (in the contract)

The single named owner is the point. Shared ownership with no one at the top works until something breaks.

What a named owner is actually accountable for

An owner who only appears on a slide isn’t an owner. Define these responsibilities in writing:

1. Inventory. The agent is registered, with its purpose, systems, and data it can reach.

2. Identity. It has its own credential, not a shared or personal one, with a defined expiry.

3. Scope. Permissions match the task and nothing more.

4. Spend. There is a budget, a hard cap where the provider allows one, and an alert when usage changes shape.

5. Human approval. Risky actions, such as sending external messages or changing records, require sign-off.

6. Logging. You can show which agent did what, when, and under whose authority.

7. Shutdown. There’s a tested way to disable the agent and revoke access quickly, including when the owner leaves.

If you can’t show items 2 and 6 within an hour of an incident, you don’t yet have ownership. You have a hope.

Questions to ask your AI service provider before you sign

If a provider is building, hosting or managing agents for you, ownership has to be written into the relationship. Ask:

• Who holds the credentials, and can we rotate or revoke them without your help?

• What logs do you keep, for how long, and can we export them?

• How do you notify us of an incident or unusual usage, and how fast?

• What spending limits or rate limits can be enforced on our account?

• What happens to the agent’s access when our named owner or your engineer leaves?

• Which responsibilities are yours, which are ours, and where does that appear in the contract?

Have counsel review any answers that shape liability, indemnity or data handling.

A 30-day starting plan

Week 1: Find them. List every AI agent, plugin and automation in use, including ones that arrived without a formal review.

Week 2: Name owners. Assign one accountable owner per agent and record it.

Week 3: Set limits. Replace shared keys, tighten permissions, set spend caps and alerts.

Week 4: Test it. Run a short drill. Revoke an agent’s access, then confirm you can reconstruct what it did.

Frequently asked questions

Who owns an AI agent when a vendor runs it?

You do. The vendor is accountable for what the contract says it is, but your organization remains the one customers, regulators and courts look to. Write the split into the agreement.

Should the CISO own AI agents?

Usually not alone. Security should monitor and respond, but the business owner holds purpose and budget. The CISO often ends up answering the board’s questions anyway, which is why roles should be agreed before an incident.

Is AI agent ownership required by law?

It depends on your jurisdiction and industry, and requirements are changing. NIST’s framework is voluntary. Ask qualified legal counsel what applies to you.

What if we don’t know every agent we’re running?

Start there. You can’t assign ownership, cap spend or review access for something you haven’t found.

Choosing providers who make ownership easier

Ownership is easier when the provider you choose supports it, with scoped credentials, usable logs and clear contract terms. AGI Beacon matches buyers with technology services providers. Talk to us about evaluating AI service providers.