Your AI Agent Has Access. Who Gave It Authority? Key Takeaways from the NYC CxO Security Forum
By Michael Hiskey
As AI agents move from answering questions to taking action, security leaders face a familiar identity problem with a fundamentally different level of risk: access is no longer just about who can log in. It is about what autonomous systems can do, what they are allowed to decide, and whether anyone can explain their actions when something goes wrong.
If an AI agent logs in as you, uses your credentials, accesses sensitive information, and does something you never intended, what will the logs say?
Probably that you did it.
That question kept coming back during our October 20 NYC CxO Security Forum, where we brought together senior security, technology, risk, and legal leaders at the DLA Piper offices in New York City. Our discussion focused on a challenge that is rapidly moving from the theoretical to the operational: what happens when non-human identities begin doing considerably more than running a scheduled job?
For years, security teams have worked to understand service accounts, application identities, privileged access, multifactor authentication, and identity governance. Those challenges have not disappeared. In many organizations, they remain unfinished business.
Now we are adding AI assistants and increasingly autonomous agents that can interact with enterprise systems, use tools, retrieve information, and make decisions about what to do next. Some can continue executing a sequence of actions without a person reviewing every step.
The result is not simply another identity category to manage. It is a new set of questions about authority, accountability, and control.
Our discussion connected familiar identity-management problems with emerging risks, incident-response realities, legal obligations, and practical approaches to governing AI agents. As always, the conversation was peer-led and conducted under the Chatham House Rule, allowing participants to share candid observations without attributing individual comments to specific contributors.
Throughout the course of the day, several themes stood out.
1. We Are Still Finishing the Last Identity Project
One question I hear repeatedly from CISOs is deceptively simple: What is actually new in identity?
Organizations have spent years investing in directories, single sign-on, federation, identity governance, access reviews, MFA, and privileged access management. The industry has also generated a steady stream of new product categories and acronyms, each promising to solve the next identity challenge.
Meanwhile, some organizations are still trying to complete the work they started years ago.
Access reviews remain inconsistent. Service accounts accumulate permissions. Legacy integrations continue operating long after their original owners have moved on. Technical debt creates exceptions that become permanent. And the people responsible for individual identities are not always clear.
Introducing AI agents does not make those problems disappear. In fact, it can make their consequences considerably more serious.
One observation from the forum captured the issue particularly well:
“We’re giving human-level access to agents, but agents don’t have human-level judgment.”
An employee may have accumulated access over a decade of working in an organization. That employee might technically be able to reach thousands of documents, applications, and data sources, but practical limitations, organizational knowledge, and human judgment influence what they actually do.
Connect an AI assistant to that employee’s account, and information that was previously difficult to find may suddenly become accessible through a simple prompt. Connect the same assistant to multiple systems, and the potential exposure expands.
The permissions may not have changed. The speed and scale at which those permissions can be exercised have.
This is one of the most important distinctions security leaders need to understand. An identity can be properly authenticated and still have far more authority than a particular task requires.
We also discussed the rise of citizen developers: business users who can build functioning applications and automations without necessarily understanding all the security implications of credentials, public repositories, or deployment configurations.
One example involved organizational information and an embedded password appearing in publicly accessible code.
The application worked. The business user accomplished the intended task. Security discovered the exposure afterward.
That is not necessarily a story about a malicious employee or a sophisticated attacker. It is a story about how easily useful technology can outrun the governance surrounding it.
As AI makes application development and automation more accessible, security teams need to consider not only what professional developers deploy, but also what business users create, connect, and expose along the way.
2. The Investigation Starts With Questions You Should Answer Today
Ron Plesco, Partner at DLA Piper and former president of the National Cyber Forensic Training Alliance (NCFTA), brought an incident-response perspective to the conversation through his session, Agents, Access & Accountability.
His contribution connected the identity discussion to the questions that become urgent when something goes wrong.
Which credential was used? What did the agent access? Who gave it instructions? Was information viewed, modified, or transmitted? Which systems were involved? Can anyone reconstruct the sequence of events?
These sound like standard incident-response questions. The challenge is answering them in an environment containing dozens of integrations, service accounts, third-party applications, legacy automations, and newly deployed AI agents.
An organization may know that an agent exists without knowing precisely what it can access. It may know which employee initiated a workflow without being able to distinguish the employee’s actions from the agent’s subsequent decisions. It may have logs but lack the context needed to interpret them.
As the discussion emphasized:
“Document what all those agents do, those service accounts and what they do.”
Documentation is not particularly exciting, but it becomes invaluable when an incident response team needs to understand how the business actually operates.
For each identity or agent, organizations should be able to answer several basic questions:
- Purpose: What business process does this identity support?
- Ownership: Who is accountable for the identity, application, or agent?
- Authority: Which systems, data, operations, and destinations can it access?
- Dependencies: What stops working if its access is revoked?
- Expected behavior: What does normal activity look like?
- Evidence: Can the organization reconstruct what happened and distinguish human instructions from automated actions?
The last point is especially important. If an agent uses a human’s credentials, the resulting audit trail may attribute activity to the human even when the person neither performed nor directly approved the action.
That creates a difficult problem for security operations, investigations, and legal teams. Attribution becomes less reliable precisely when it matters most.
The answer begins with better identity separation, meaningful logging, documented ownership, and an understanding of the agent’s expected behavior before it enters production.
The legal obligations cannot wait for the incident
The discussion also moved beyond technical controls to the contractual and regulatory obligations that govern incident response.
Security teams may know that legal reviewed a vendor agreement. That does not mean they can immediately explain how the contract defines an incident, which information is covered, who must be notified, or when the notification deadline begins.
One practical recommendation from the conversation was:
“Talk to your general counsel. Develop a table.”
The idea is straightforward: build an obligations register before an incident occurs.
That register should help the organization identify applicable requirements, contractual definitions, notification deadlines, responsible parties, and internal decision-makers. It should also make clear where security, legal, privacy, compliance, and business leadership must coordinate.
For organizations subject to New York Department of Financial Services (NYDFS) cybersecurity requirements, those obligations need to be understood alongside customer contracts and other applicable rules.
AI agents add another layer of complexity. If an agent accesses or transmits sensitive information, does that activity trigger an existing contractual obligation? If an agent is compromised, how will the organization establish what information was exposed? If an autonomous workflow interacts with a third party, who determines whether the resulting activity constitutes an incident?
These are not questions that should be answered for the first time during a crisis.
Security and legal teams need to understand how AI agents operate, where their permissions come from, and what evidence will be available if their actions create a problem.
3. Three Emerging Solutions, Three Connected Problems
A special thank-you to AWS Startups and Thomas J. Klein for supporting the community and bringing Transcend, Outtake, and Teleskope into the discussion.
The AWS Startups relationship gave us an opportunity to examine emerging solutions through substantive questions about the problems they address, how they work, and where they might fit into real enterprise environments.
What made the three showcases particularly interesting was how closely their respective areas of focus connected.
Transcend: Access Is Not the Same as Permission to Act
Transcend focused on governing permission at the moment an action takes place.
A healthcare example made the distinction clear. An AI agent might have access to the same patient records for two different purposes: approved research and marketing. The fact that the agent can access the records does not mean every possible use of those records is appropriate.
The context matters.
Jess Dandorph described an approach in which policy can allow an action, deny it, or escalate it to a human for review. An audit trail can then help explain what happened and why the action was permitted.
This introduces an important distinction for AI governance: access control answers what an identity can reach, while action-level policy can help determine whether a specific use is appropriate in a particular context.
As organizations deploy more autonomous workflows, that distinction becomes increasingly important.
It is not enough to know that an agent had permission to access a system. Security teams need to understand whether the action it took was permitted for the purpose it was pursuing.
Outtake: Can You Trust the Other Side of the Interaction?
Outtake brought the discussion beyond the enterprise perimeter.
Alex Arjun Dhillon described the growing problem of impersonation, fraudulent websites, and other deceptive content, along with the challenge of identifying, classifying, and removing those threats.
The conversation raised a question with particular relevance to an increasingly agent-driven internet:
“Can you trust a counterparty that you’re about to interact with on this increasingly agentic internet?”
Organizations have traditionally focused heavily on protecting their own users, applications, and infrastructure. But what happens when an AI agent begins interacting with the outside world on the organization’s behalf?
An agent may search for information, visit websites, retrieve documents, communicate with external services, or initiate transactions. It may encounter a convincing impersonation of a legitimate supplier, a fraudulent login page, or content designed to manipulate its behavior.
The risk is no longer limited to a human employee being fooled by a deceptive message. An automated system may encounter and act on deceptive information while carrying organizational data, credentials, or delegated authority.
This makes the trustworthiness of external counterparties an important part of the broader agent-security discussion.
Organizations must think about not only what their agents can do internally, but also where those agents can go, what they can interact with, and how they determine whether an external destination is legitimate.
Teleskope: AI Makes Old Data Exposure Problems Easier to Exploit
Teleskope addressed another fundamental issue: the relationship between data exposure and access permissions.
Lizzy Nammour described how AI copilots can make existing permission problems much easier to exploit. When an assistant can search across organizational content, retrieve information, and synthesize results, excessive permissions can become more consequential.
The issue is not necessarily that AI creates new access to information. It may instead make existing access far more useful to someone who should not have it.
A memorable example illustrated the importance of context. Identifying a Social Security number in a document provides one piece of information. Recognizing that the document is the CEO’s W-2 and that it is shared across the organization provides a much clearer picture of the risk.
Data discovery is valuable, but discovery alone can leave security teams with a mountain of findings and a substantial manual remediation burden.
The next questions are more operational: Who should have access? Why is the information exposed? Which permissions are excessive? Can the organization correct the problem without interrupting legitimate business activity?
That requires context, policy, and a reliable ability to act where the data resides.
Taken together, the three discussions highlighted a connected set of challenges: governing actions, establishing trust in external interactions, and ensuring that sensitive data is accessible only in appropriate circumstances.
None of these problems can be solved by authentication alone.
4. Standing Privilege Is an Agent-Security Problem, Too
Ambient Security, which supported the gathering, was particularly well positioned to contribute to this conversation.
Its focus on identity visibility, excessive access, and replacing standing administrator privileges with just-in-time access addressed a problem that repeatedly surfaced throughout the afternoon.
Before deciding how much autonomy to give an AI agent, organizations need to understand how much authority is already available to it.
Standing privilege creates a persistent exposure. An account with powerful permissions may retain those permissions even when they are not needed. If the account is misused or compromised, the available authority can make the consequences significantly worse.
The same concern applies to non-human identities, including service accounts, application identities, and AI agents.
Three related principles deserve attention:
- Just-enough access: Provide only the permissions necessary for the task.
- Just-in-time access: Make elevated permissions available when needed rather than indefinitely.
- Zero Standing Privilege: Reduce or eliminate permanently available privileged access wherever practical.
These principles help address different aspects of the same problem: how much authority an identity possesses, when that authority is available, and how much unnecessary privilege remains exposed.
For AI agents, the questions become especially important. An agent may execute tasks quickly, interact with multiple systems, and continue through a workflow with limited human intervention. Excessive standing privilege can magnify the impact of an unexpected action or compromised identity.
Just-in-time and just-enough access are therefore not simply refinements to traditional identity management. They are important building blocks for controlling the authority of autonomous systems.
The broader lesson is that organizations should not begin by asking how much access an agent needs to perform everything it might conceivably be asked to do.
They should begin by understanding the specific task, defining the necessary permissions, and limiting access accordingly.
We appreciate Ambient Security’s support for a community willing to examine these practical challenges in depth.
Comments
I welcome your input on this article… please do that via the summary LinkedIn post on this same topic!
5. Give the Agent Its Own Identity From Day One
Timothy Rohrbaugh, founder of RadicalNotion.AI and former JetBlue CISO, challenged the group to approach the problem without adding unnecessary complexity.
Organizations already have established ways to manage service accounts, application accounts, and other non-human identities. Those foundations remain useful.
The difference is that model-driven systems can choose among different actions, even when a request initially appears similar. An AI agent is not necessarily executing one fixed sequence of instructions every time it runs.
That makes it important to distinguish between different levels of automation.
As Tim put it:
“It’s one thing to give it access tools. It’s another thing to do full automation.”
An AI application might provide an answer, recommend a course of action, prepare a change for human approval, or execute a sequence of actions independently. Each step introduces a different level of authority and potential exposure.
A system that drafts a recommendation is not equivalent to one that can modify production infrastructure, access financial records, or transmit sensitive information to an external destination.
Security controls should reflect that difference.
Separate the agent’s identity from the developer’s identity
One of the most practical proposals from the discussion was to give agent activity a separate identity from day one.
Many organizations already distinguish between an employee’s everyday account and a privileged administrator account. A similar separation can help distinguish the actions of an AI agent from those of the person who developed, deployed, or initiated it.
The principle is simple: do not borrow a human identity when a dedicated identity can provide clearer attribution and tighter control.
Start with limited authority. Define the resources the agent needs to access. Specify which operations it can perform and which destinations it can reach. Expand permissions only when a demonstrated business requirement justifies doing so.
As another observation from the conversation put it:
“I am more of the white listing approach, where you define exactly what you need along the way.”
A defined allowlist of required resources, operations, and destinations gives security teams something concrete to evaluate during a production review.
It also makes investigations easier. If the agent has its own identity, logs can more clearly distinguish the software that acted from the human who initiated the work.
That separation is particularly valuable when the agent takes an unexpected action. Without it, investigators may struggle to determine whether the action was performed directly by an employee, initiated through an application, or selected autonomously by the model.
The goal is not to make identity management more complicated for its own sake. It is to make authority explicit and activity attributable.
6. Which Model Did You Approve?
Identity is only part of the challenge. The model itself matters, too.
A workflow tested against one model may behave differently after an upgrade, a model change, or a deprecation. Even if the business process remains unchanged, the application’s behavior may not.
That creates a governance question that traditional software change management does not always address in the same way: what happens when a component responsible for interpreting instructions and choosing actions changes?
If an agent has access to sensitive systems, a change in model behavior could affect how it uses that access.
Organizations should therefore consider model version, provenance, evaluation, and change management as part of the broader security design. Knowing which model was approved is a starting point, but it does not eliminate the need to test whether that model remains appropriate for the intended application.
Tim also challenged the group to learn more about open-weight models and deployment on infrastructure an organization controls. That led to a related discussion about cost and architecture.
His observation was concise:
“I think about watts per transaction.”
The point was to think about the practical economics of running AI workloads, not simply the headline cost of a model or service.
Local deployment may offer meaningful control over infrastructure and data flows, but it also introduces engineering, operational, and security responsibilities. The right choice depends on the workload, its requirements, the data involved, and the organization’s ability to manage the environment.
Tim’s ModelDNA project offers a place to explore model lineage and provenance. Understanding what model was obtained and where it came from is an important part of evaluation, but provenance does not replace testing for a particular use case.
For security leaders, the broader takeaway is that AI governance needs to account for both identity and the changing software components that exercise that identity.
7. Accounts, Access, and Accountability
As the conversation came to a close, three questions provided a useful way to organize the issues discussed throughout the afternoon.
Accounts: Do we know which identities exist and who owns them?
This includes human users, service accounts, application identities, machine identities, and AI agents. Each should have a defined purpose, an accountable owner, and a clear lifecycle.
Access: What can each identity do, and how much authority is actually necessary?
Organizations need to understand permissions in context, reduce excessive privilege, and consider whether access should be permanent or granted only when required. They also need to distinguish between an identity’s ability to access information and its authority to take a particular action.
Accountability: Can we explain who approved an action, what actually acted, and why the action was allowed?
This requires meaningful audit trails, documented policies, appropriate logging, and a clear distinction between human decisions and automated activity.
These questions are not unique to AI. They are the foundations of effective identity and access management.
What has changed is the urgency with which organizations need to answer them.
The closing discussion about applying just-in-time privilege to AI agents highlighted the implementation challenges still ahead. Controls designed around a human approval process, a physical interaction, or a hardware token do not automatically translate to software that can operate autonomously.
The answer will not be one product, one policy, or one new acronym. It will require organizations to connect identity management, data governance, security operations, legal oversight, and AI development practices.
Most importantly, it requires security leaders to make deliberate decisions about the authority they are granting.
8. What Should CISOs Do Next?
The conversation generated plenty of questions that deserve further discussion, but there is a straightforward way to start.
Choose one AI agent or automated workflow already operating in your environment. It does not have to be the most sophisticated or the most strategically important system. In fact, a relatively simple example may be the best place to begin.
Then trace its identity, permissions, and activity all the way through.
Ask who owns it, which credentials it uses, which systems it can reach, what data it can retrieve, what actions it can perform, and whether it can interact with external destinations.
Determine whether it operates under a dedicated identity or inherits a person’s permissions. Establish whether its actions are logged in a way that distinguishes the agent from the person who initiated the work. Identify what would happen if its credentials were compromised or its behavior changed unexpectedly.
Finally, ask whether the organization could explain its activity to an incident-response team, general counsel, a regulator, or an affected customer.
If the answer is unclear, you have found a useful starting point.
That exercise may reveal gaps in ownership, excessive privilege, undocumented integrations, weak audit trails, or contractual questions that have not been addressed. Those findings are valuable because they turn an abstract discussion about AI risk into a specific set of improvements.
It also gives the organization a practical foundation for evaluating additional agents before they are introduced into more sensitive environments.
The objective is not to prevent every use of AI or to treat every agent as inherently dangerous. It is to make sure that the authority granted to an agent is deliberate, limited, visible, and accountable.
The Value of the Peer Conversation
One of the reasons I value the CxO Security Forum format is that it gives practitioners room to examine these issues without turning every discussion into a product demonstration.
The questions raised during this session were practical, sometimes uncomfortable, and directly relevant to the decisions security leaders are making now. The discussion moved naturally from identity fundamentals to incident response, legal obligations, emerging solutions, privilege management, and model governance.
No one left with every implementation question resolved. That was never the objective.
The value was in connecting problems that are often handled separately and identifying the questions that deserve attention before an incident forces the issue.
My thanks to our hosts at DLA Piper, our partners at Ambient Security and AWS Startups, our discussion leaders, and everyone who contributed candidly. A special thank-you to John Bryson of Western Alliance Bank for his continued support of the community, and to Jeff Klein and the exemplary DLA Piper team for helping make the gathering possible.
As AI agents become more capable, organizations will need to think carefully about the relationship between identity, authority, and accountability.
An agent may have valid credentials. It may be operating exactly as its software was designed to operate. It may even be using permissions that have existed for years.
None of those facts, on their own, establishes that the action it takes is appropriate.
The question is no longer simply whether your AI agent has access. It is who gave it that authority, what limits govern its decisions, and whether you can explain what it did when it matters most.
We called about your agent. Could you explain what it did?
That is a conversation worth having before the incident begins.
Comments
I welcome your input on this article… please do that via the summary LinkedIn post on this same topic!