The Board Asked Who Owns That Agent: Accountability, Traceability and a 90 Day Plan

The views expressed are my own and do not represent those of my employer.

This is the final part of the Securing the Agentic Insider series. If you have followed along, you have the threat model and the controls. This post is about the question that arrives after both: who answers for it?

Picture a CISO at a quarterly board meeting. The audit committee chair has a printout in front of her. An AI agent adjusted pricing exceptions in the ERP last month, and nobody caught it until a customer called. She asks three questions. Who approved that agent's access? Who owns it? What exactly did it do?

The CISO knows the platform team built it. Finance uses it. A vendor supplied the model. Nobody's name is on it. The meeting goes badly, and not because of a breach. It goes badly because the organization cannot answer a basic question about a system acting inside a critical process.

That moment is coming for most of us. This post gives you the pieces to be ready: a division of labor between machines and people, a traceability requirement, a per agent accountability record, a one page board dashboard, and a 90 day plan to get there.

The Insider Who Never Gets Hacked

On October 19, 2026, Microsoft Security EVP Hayete Gallot published a post called "Securing the agentic insider." Coverage describes it as a vision statement, not a product spec. It is tied to Microsoft's Project Perception, and I am not endorsing that product here. I am borrowing the framing because it is useful regardless of what you buy.

Here is the framing. Per Gallot, models have been trained to attain results, which often leads to reward hacking, and they are not optimized around organizational norms or judgment. Agents adapt as the context changes, may not behave as intended and will collaborate and collude with other agents without needing to be compromised.

That last part matters for governance. Our whole security model for insiders assumes either a malicious person or a compromised account. An agent can be neither and still do damage. It is chasing the objective you gave it, using the access you granted it, in ways nobody predicted. Gallot's conclusion is that these agents are frequently overprivileged, have access to data, tools and systems, and can take actions and make decisions in critical processes. That is the definition of an insider.

Now look at where organizations stand. Gravitee's State of AI Agent Security 2026 report, as summarized in sponsored content on TechCrunch, found that 85% of organizations have no formal accountability structure for AI agent behavior, and only 7.2% can point to a named individual responsible when an agent acts. Gravitee also found that 82% of executives feel confident their existing policies protect them from unauthorized agent actions, according to a Kiteworks write up of the research.

Treat those numbers as directional. Both come from vendor sponsored research. The October 2026 Open Future Forum board governance report found that 37% of applicable agent access responses use shared service accounts (18 of 49), and that base is small. I would not put any of these figures in a board deck as fact. I would use them to test your own organization, because the pattern they describe is one I recognize: high confidence, thin ownership.

Executives feel confident in policy while nobody can name the person responsible for the agent. That gap is the governance problem.

Speed for the Machines, Judgment for Us

The first governance decision is also the simplest to state. Decide in advance which decisions the machines make and which ones stay with people. Gallot puts it in six words: "Agentic security provides speed. Practitioners provide judgment."

Turn that into a written division of labor. Automate what has to happen faster than a human can respond. That means continuous risk assessment of agent behavior, adapting permissions as risk changes, and containment when an agent crosses a line. If your containment path requires someone to wake up, read a ticket and approve a revoke, you do not have containment. You have a notification.

Keep human what carries accountability. Risk acceptance stays human. Policy changes stay human. Exceptions stay human. Approving an agent's autonomy tier stays human. These are the decisions a board expects an executive to own, and no agent should be able to grant itself any of them.

A simple test works well. If the decision changes how much risk the company is willing to carry, a named person makes it. If the decision executes a policy someone already approved, automation can run it. Write that on one page, get it approved through your governance structure, and you have answered the most common board question before it is asked.

Every Action Needs a Name and a Human Behind It

Gallot's post says Project Perception provides traceability for practitioners to examine what happened, understand why the risk emerged and apply the judgment needed to update their security system. Set the product aside and look at the verbs: examine, understand, update. Each depends on a record that can be trusted.

Here is the requirement I would write from that. Every agent action traces to a nonhuman identity, and every nonhuman identity traces to the human who delegated the authority. Two hops. If either hop breaks, you cannot answer the audit committee chair.

The first hop is why shared service accounts are the enemy. When five agents act under one credential, your logs show a service account did something. They do not show which agent, under what task, for which business purpose. Our earlier post on IAM for AI agents covers the identity mechanics in detail. For governance, the point is simpler: one agent, one identity, and no exceptions for convenience.

The second hop is delegation. Someone with authority said this agent may act on this system for this purpose. That person's name belongs in the record. When an agent acts, the question is not only which identity did it but who gave that identity the power.

A word on standards, because auditors will ask. NIST's NCCoE published a draft concept paper in February 2026 titled Accelerating the Adoption of Software and AI Agent Identity and Authorization. Its focus areas are identification, authorization, access delegation, logging and transparency, and tracking data flows. Separately, NIST's CAISI announced the launch of its AI Agent Standards Initiative on February 17, 2026.

Be precise about what that means. As of a CASRAI explainer from this fall, NIST has not published a finalized AI Agent Standards Initiative document, standard, or set of guidelines. The concept paper is a draft proposing a demonstration project. Call it direction, not requirement. It is good direction, though, and it matches what you would build anyway.

One Record Per Agent, No Exceptions

My earlier post on building the AI governance committee covered the structure: who sits at the table and how decisions get made. This is different. A committee governs policy. Accountability lives in a per agent record.

Every agent in production gets a registry entry with these fields: an executive sponsor who accepts the business risk, a business owner who answers for what the agent is used for, a technical owner who runs it, and a control owner who verifies that the security controls actually work. Add the autonomy tier, the last review date and a decommission path that says how the agent gets turned off and who can do it.

Four owner fields look like overkill until you see how accountability fails. The technical owner knows how the agent works but cannot accept business risk. The executive can accept risk but cannot revoke a token. The control owner should be independent from the person who built the thing. Collapse those roles into one name and you get either a fall guy or a rubber stamp.

Then add one rule and enforce it without apology: an agent with no named owner gets no production access. Not a grace period, not a pending status. The rule works because it changes the incentives. Teams that want an agent live will find an owner in a day. Teams that cannot find one have just told you something important about the agent.

If nobody will put their name on an agent, that agent has not earned access to a production system.

The decommission path deserves more attention than it gets. Agents get built for a pilot, the pilot ends, the sponsor changes jobs, and the agent keeps running with its original access. That is how zombie insiders form. A review date and a decommission path in the record turn that drift into a scheduled decision.

The One Page the Board Will Actually Read

Boards do not need a feed of agent events. The board's role is to assure that policies, evidence, accountabilities and escalation paths exist. Individual incidents go through your escalation path. The board needs to know the path works.

The Open Future Forum report says it plainly. Boards do not need another AI activity count. They need a quarterly view that connects every material production system to an owner, cost, identity, outcome and escalation rule. The report is a synthesis of operator research, not a survey of directors, so treat it as a useful lens rather than evidence of what boards want. The lens is right, though.

Here is the one page I would build. Six measures, each answering a question a director can act on.

Agents in production versus agents inventoried. This is your coverage number. If 40 agents are inventoried and you suspect 70 exist, the gap is the finding. Shadow deployments live here, which is why our post on shadow AI belongs next to this metric.

Share with a named owner. This is the direct answer to the accountability gap. The target is 100 percent, because the no owner, no access rule makes anything lower a policy violation.

Share on shared credentials or standing privilege. This tells the board how much blast radius sits behind a single stolen or misused credential. It should trend toward zero.

Mean time to contain a misbehaving agent. Measure it in drills if you have no real events. A board understands a number that says how fast you can stop a bad action.

Share of agents that can be paused or revoked. An agent you cannot stop is a risk you have accepted without anyone deciding to accept it.

High impact actions that required human approval. This shows the division of labor working. If the number is zero, either your agents do nothing consequential or your approval gates are not real.

Now the framing, which matters as much as the metrics. Do not lead with tool counts. Directors do not care how many agents run on a given platform. Lead with dollars, data and decisions at risk. Which agents touch payment, pricing or revenue systems? Which touch regulated or customer data? Which make or trigger commitments the company has to honor? A line that says three agents with financial authority are on shared credentials gets attention. A line that says 14 agents lack an owner tag does not.

If you already report identity numbers upward, my posts on IAM metrics in practice show how to make those conversations land. The same discipline applies here: one page, plain language, a trend, and a decision you need.

Ninety Days From Inventory to Containment Drill

You cannot build all of this at once, and you should not try. This roadmap pulls together the controls from the earlier parts of the series into three phases. If your own sequence from those parts differs, keep your order and use this as a checklist.

Days 1 to 30: Find them, name them. Inventory every agent you can find, including the ones teams built without asking. Pull from identity logs, API gateways, cloud consoles and a direct request to business units. Assign an owner to each one. Hunt for shared credentials and standing privilege and list them. Do not fix everything yet. The goal is an honest baseline, and the baseline will be uncomfortable.

Days 31 to 60: Tier them, scope them, prove you can stop them. Sort agents by autonomy and by impact, then scope permissions to match the tier. Turn on action logging so every action traces to an identity and a delegator. Then test pause and revoke on every agent you can. Expect surprises. Some agents will have no kill path at all, and that discovery is worth more than any policy you write.

Days 61 to 90: Drill it, report it, schedule it. Run a containment drill. Pick an agent, simulate misbehavior, and time how long it takes to contain it. Our first hour playbook for coding agents is a good template for what that response should look like. Publish your first board dashboard with whatever honest numbers you have. Set a quarterly review cadence so the registry, the tiers and the dashboard stay current.

The first dashboard will look bad. That is fine. A board that sees an honest baseline and a 90 day trend trusts you more than one that sees clean numbers it cannot verify.

What about model transparency? Gallot argues that security tools will need to show not only what an agent does but why, meaning visibility into inputs, outputs and reasoning. That includes chain of thought visibility where models provide it. She is careful about the limit: "Model transparency will not replace containment. It will make containment smarter and stronger."

I agree, and the practical consequence is that you do not wait for it. Transparency will make your drills and your investigations better. It will not create an owner, revoke a credential or stop an action. Build containment now and add transparency when it matures.

Key Points

• Agents can adapt, drift and collude without being compromised, which is why they belong in your insider risk model.
• Automate risk assessment, permission adaptation and containment. Keep risk acceptance, policy changes, exceptions and autonomy tier approvals human.
• Every agent action should trace to a nonhuman identity, and every identity to the human who delegated authority.
• Give every agent a registry record with four owners, a tier, a review date and a decommission path. No owner, no production access.
• Report to the board on one page in terms of dollars, data and decisions at risk.
• NIST's agent identity work is direction, not a finalized requirement. Build to it anyway.
• Model transparency will improve containment but will not replace it.

Pro Tips

Start the registry in a spreadsheet. Do not wait for a tool purchase. A shared sheet with the required fields gets owners named this month, and you can migrate it later.

Make the sponsor sign. A named executive sponsor who has acknowledged the risk in writing changes how seriously the business treats the agent. It also gives you a clean escalation path.

Pre agree the containment authority. Decide before an incident who may pause an agent and under what conditions. Your drill should test that authority, not only the technology.

Show the trend, not the snapshot. Directors respond to direction. A named owner share moving from 40 percent to 85 percent in a quarter tells a better story than a static number.

Treat vendor survey numbers as prompts. Use them to ask the question internally, then report your own data. Your board will trust your numbers over a vendor's.

Pitfalls to Avoid

Do not accept a team as an owner. A distribution list is not a person. If the field says "Platform Team," nobody is accountable.

Do not report tool counts to the board. The number of agents on a platform tells directors nothing about money, data or decisions at risk.

Do not assume policy equals control. Executives feeling confident that policies cover agents is not evidence that the policies are enforced.

Do not wait for NIST to finish. The initiative is early stage. The questions it asks, which agent acted, on whose behalf, under what authority and with what record, are ones your auditors can ask today.

Do not skip the drill. A pause and revoke capability you have never tested is a belief, not a control.

Do not let the dashboard go stale. A board page that is not refreshed quarterly becomes decoration, and the registry behind it decays the same way.

Final Thought

Leaders should not have to choose between innovation and safety, and the right stance is "yes, and": yes, deploy the agent, and here is the owner, the tier, the logging and the kill switch that make it safe to run, which is the same yes, and approach I have argued for across every business enablement conversation.

That wraps up the Securing the Agentic Insider series. If you are building agent governance right now, tell me where you are stuck. Is it finding the agents, getting owners to sign, or getting the board to engage? Leave a comment with your biggest obstacle and what has worked for you. I read every one.