AI agents are moving organizations from helping people work to doing work on their behalf. That sounds efficient, until you ask the harder question: if an agent can take action, update a record, trigger a workflow, or send something out, who is responsible when it uses the wrong information?
In this conversation, Jacqueline Stockwell and Kunal Kankariya unpack the practical difference between assistants and agents, the information governance risks that come with autonomous action, and the controls organizations should put in place before deployment. If you’re responsible for information, compliance, security, or AI strategy, this is the question you need to answer before agents go live: who owns the information risk?
The Difference Between an AI Assistant and an AI Agent
The easiest way to understand the shift is this: an assistant writes your draft, but an agent sends it.
An assistant, like a Copilot-style tool, helps you summarize a meeting, tidy up an email, or draft a response. It gives you an answer and then stops. Nothing happens in the real world until you decide to act. That matters, because you are still the safety net. You can check the output, correct it, and choose whether to use it.
An agent is different. It is given a goal rather than just a question. It can plan steps, call systems, move processes along, file a document, update a record, or reply to a customer. In some cases, it may even be triggered automatically by an event.
That is the real governance shift. The question is no longer only, “Is the answer good?” It becomes, “What did it just do, and who allowed that action?”
Kunal made an important distinction here: not everything called an “agent” behaves the same way. Some experiences in Microsoft 365 are still fairly reactive, like a SharePoint agent that answers questions about one site or a declarative agent that follows instructions. Others, built in Copilot Studio with triggers, can run on their own and act without waiting for a user prompt. That is where the risks become more serious.
If you’re defining an AI project, start with one question: Does it just answer, or does it act?
That one question changes everything about how you govern it.
Why Bad Information Becomes a Bigger Problem with AI Agents
Kunal’s point was simple and unsettling: everything that has already gone wrong with your information will go wrong faster once an agent is involved.
If information is overexposed, stale, or badly classified, an agent does not magically fix that. It can amplify it.
Overexposed information gets used
If a folder containing salary data was accidentally shared too widely years ago, a human might never stumble across it. An agent, however, can. If it has access, it may pull that information into a process, a response, or a workflow.
That means a permission mistake that used to sit quietly in the background can suddenly become operational.
The problem was always there. The agent just makes it matter.
Stale information can trigger bad decisions
With an assistant, quoting an old policy is embarrassing. With an agent, acting on an old policy can cost real money.
Imagine a refund-approval agent working off an outdated policy version. Instead of just summarizing the wrong rule, it could approve a refund it shouldn’t. That changes the consequences from “incorrect output” to “incorrect action.”
The same is true in any process where timing matters—contracts, approvals, case handling, service requests, or records retention. If the knowledge is stale, the action is stale too.
Hidden instructions can be embedded in content
This is the risk that makes security teams sit up.
Agents read emails, documents, web pages, and other sources. If those sources contain hidden instructions, an attacker may try to manipulate the agent’s behaviour. In the transcript, Kunal referenced the EchoLeak research as an example of how crafted content can push Microsoft 365 Copilot into exposing internal information.
Even when a platform patch exists and there is no evidence of real-world abuse, the lesson stands: if an agent can read content, someone may try to talk to it.
AI Agents can outlive the person who built them
This is an underrated governance issue. Someone creates an agent, shares it widely, and then leaves the organization. The agent keeps running, and nobody is really watching it anymore.
That is not a technical novelty. It is a governance failure.
The key takeaway is this: agents do not create entirely new information risks—they remove the delay that used to protect you from old ones.
The Three Layers of Control You Need Before You Deploy
If agents increase the speed and impact of information problems, the controls need to exist at three levels:
Control the information first
Before you let an agent act, you need to know what information it can reach and whether that information should be reachable at all.
That means finding overshared content, labeling sensitive data, and using data loss prevention to keep restricted information away from copilots and agents. In Microsoft 365, this may involve Microsoft Purview data security posture management, sensitivity labels, and DLP for Copilot. It can also include Restricted Content Discovery in SharePoint Advanced Management to keep certain content out of reach while you fix the underlying issue.
This is important because you usually cannot clean up years of bad information hygiene overnight. You need immediate guardrails that stop the bleeding while longer-term remediation happens.
Control the AI agent itself
The second layer is about the agent as an entity.
Who is allowed to build it? Who can share it? Who approves it before it is published broadly? Which connectors can it use? Which data can it touch? Does it require the maker’s own access, or does it have its own identity?
Kunal pointed out that Microsoft 365 now has a dedicated area for managing agents, and Entra can give agents their own identity so they can be governed more like users. That matters because if an agent is effectively another actor in the organization, it should be managed like one.
That means:
- Clear policies for building and sharing agents
- Approval workflows before broad deployment
- Boundary settings for what the agent may access
- Access reviews for agents, just like people
In other words, the question is not only “Can we build it?” It is “Should this agent exist in this form, with these permissions, for these people?”
Monitor what the AI agent does
Even with controls in place, you need visibility.
Audit logs matter. A lot. They tell you what the agent did, when it did it, and who or what triggered it. Without logs, you may not know something has gone wrong until the damage has already spread.
That is why the first thing Kunal recommended, very plainly, was: turn on your audit logs.
This is also where retention and monitoring policies help. If an agent creates, moves, or deletes content, you need a record of that activity. Otherwise, you can’t investigate incidents, explain decisions, or prove compliance later.
Who Needs to Be in the Room?
One of the most useful parts of the conversation was the reminder that agent governance is not owned by one team.
If your organization treats this as only an IT issue or only an AI strategy issue, you will miss critical risk.
The room should include:
IT – because they run the platform
Security – because they understand misuse, attacks, and exposure
Data protection/privacy – because agents can touch personal data
Legal and risk – because approvals and liabilities matter
Records and information managers – because agents create, file, and delete content
Business process owners – because they know whether the agent is doing the right job
That last one is essential. A technical team can tell you whether an agent is secure. Only the business process owner can tell you whether it is correct.
Kunal also stressed that Microsoft’s own direction supports this model: every agent identity should have a human sponsor. Someone has to be accountable for what the agent is for, what it can access, and whether it should still exist.
That is the practical answer to the title question. Information risk is not “owned” by AI. It is owned by a person, a team, or a named sponsor who can be held accountable.
What Organizations Should Document for Accountability
If you want to govern agents properly, you need more than a policy. You need evidence.
Kunal suggested that accountability comes down to being able to answer four questions clearly:
Who owns the agent?
What can it reach?
What did it do?
Who approved it, and why?
That means creating a register of your agents. You need to know who built them, which department they belong to, and who their human sponsor is. Microsoft’s agent inventory capabilities can help here, but the bigger point is that you need a single source of truth somewhere.
You also need to document access.
What was the agent designed to reach, and what can it actually reach today? Which documents, systems, or connectors can it use? Are those permissions still appropriate? Regular access reviews should apply to agents as much as to users.
Then there is the activity record. Audit logs show what happened. That is not optional.
Finally, you need a record of approval and rationale. If someone says yes to an agent, why did they say yes? What risk did they accept? What boundary did they set? If there is an incident later, auditors will not just ask what your policy said. They will ask who decided, and whether you can prove it.
That is why the “job description for an agent” is such a useful idea. Every agent should have:
- What it does
- What it is not allowed to do
- Who supervises it
- When it is reviewed
- When it is switched off
The Board Questions That Matter Most
If a board is being asked to approve agents, the conversation has to move beyond enthusiasm.A board should ask:
What information can this agent actually reach?
How many agents are already running in the organization?
Does every agent have a name and an owner?
When does a human step in?
Which actions require approval before they happen?
How quickly will we know if something goes wrong?
How do we stop it?
Those questions force clarity around scope, accountability, and response. They also surface the most common failure mode: assuming “we think so” is good enough.
It isn’t.
If the organization cannot explain what the agent can access, who owns it, and how it is monitored, then approval is premature.
The practical shift is this: stop asking whether the agent works in a demo. Start asking whether you can explain its behaviour in the real world.
Frequently Asked Questions
What is the difference between an AI assistant and an AI agent?
An assistant helps you generate or summarize information, but you still decide what to do next. An agent can take action on your behalf, such as updating systems, triggering workflows, or moving a process forward.
Why are AI agents more risky than assistants?
Because they can turn information problems into business actions. A stale policy, overshared document, or hidden instruction may not be dangerous when it just appears in a draft, but it becomes much more serious when an agent acts on it.
What controls should be in place before deploying an AI agent?
You should control the information it can reach, the agent’s permissions and boundaries, and the monitoring around its actions. Audit logging, access reviews, and approval workflows are all essential.
Who should own AI agent risk?
A named human sponsor should own the agent, with support from IT, security, legal, privacy, records, and the relevant business process owner. AI can execute action, but accountability has to stay with people.
What should a board ask before approving AI agents?
Boards should ask what information the agent can reach, who owns it, what human approvals exist, how it will be monitored, and how quickly the organization can detect and stop a problem.
Conclusion
Agents are not just another AI feature. They are a governance event. Once software can act, the quality, access, and classification of your information matter even more—because bad information no longer just produces a bad answer; it can produce a bad outcome.
The organizations that will handle this well are the ones that treat agents like governed actors, not clever demos. They will document ownership, limit access, keep humans in the loop where it matters, and maintain evidence that explains what happened.
So before you build or approve an agent, ask the question that matters most: if it acts tomorrow, can you explain why it happened, what it used, and who owns the outcome?
