Identity, Agentic AI and Accountability: Key Takeaways from the Boston CxO Security Forum

By Michael Hiskey

As AI agents take on more responsibility across the enterprise, cybersecurity leaders face a growing challenge: ensuring that identities, permissions, governance and accountability keep pace with what technology can now do.

 

“I think identity is in a better spot than it’s ever been in the past.”

 

That was one of the most encouraging observations to emerge from the Boston CxO Security Forum on October 15, 2026. While identity and access management remain complex, organizations have more mature capabilities, better integrations and richer telemetry than ever before. AI is also creating new opportunities to accelerate implementation and reduce operational friction.

 

But the expanding population of non-human identities and increasingly autonomous AI agents introduces a new dimension of risk. The challenge is no longer simply determining who can log in. It is understanding what an identity can do, why it has that authority, whether it is being used appropriately, and who is accountable when something goes wrong.

 

At our Boston gathering, cybersecurity leaders explored these issues through candid, peer-driven discussions spanning identity modernization, non-human identity management, AI governance, legal exposure and vendor contracts.  This resulted in seven key insights security leaders can take back to their organizations.

1. Identity Is Evolving, Not Starting Over

The conversation challenged the idea that each new generation of identity technology makes the previous one obsolete. Directories, provisioning, identity governance and administration (IGA), single sign-on, multifactor authentication and privileged access management (PAM) remain essential components of the enterprise security architecture.

 

The opportunity lies in making these investments work together more effectively.

 

Organizations that have invested consistently in identity foundations are often better positioned to address emerging demands. The challenge is connecting existing capabilities, improving lifecycle management and extending governance to service accounts, workloads, machine identities and AI agents.

 

Better telemetry can also make identity reviews more meaningful. An unfamiliar account name tells a reviewer very little. Usage information, identity-provider logs and application or database logs can help establish whether an account is active, what depends on it and which team is responsible for it.

 

AI may help accelerate this work through faster connector development, assisted workflows and improved analysis of difficult-to-integrate applications. Human judgment remains essential, particularly when decisions affect sensitive access or business-critical systems.

 

The takeaway: Organizations do not necessarily need to replace their identity infrastructure to make progress. They need to connect what they already have, improve visibility and extend established controls to a changing identity landscape.

2. Non-Human Identities Are an Enterprise Governance Problem

 

AI agents are attracting considerable attention, but they are only one part of a much larger challenge. Enterprises already manage service accounts, API keys, certificates, application identities, workloads and credentials embedded in development and deployment pipelines.

 

The central question is not simply how to secure these identities. It is whether each identity should exist, where it should exist and what authority it should have.

 

As one question raised during the discussion captured it:

 

“Should this credential exist, especially in this location?”

 

Credentials can expose access when placed in source-code repositories, configuration files, environment variables or deployment workflows. Even a short-lived credential can create meaningful exposure while it remains valid.

 

Identity and application security teams therefore need a shared understanding of where credentials are created, how they are used and which permissions they enable.

 

Visibility is an important starting point, but inventory alone does not equal control. Reported ratios of non-human to human identities can vary significantly depending on whether organizations count logical identities or every account instance across connected systems.

 

The more useful questions are whether identities have accountable owners, whether their credentials are necessary, and whether their effective permissions match their intended purpose.

 

The takeaway: Measure identity coverage consistently, establish ownership and focus on the authority each identity actually possesses—not simply how many identities appear in an inventory.

3. Don’t Solve for the Agent. Solve for the Enterprise

 

One of the central themes of the discussion was that enterprise AI governance cannot be reduced to securing an individual agent or selecting a particular platform.

 

Organizations need a consistent approach to identifying, authorizing, monitoring and governing agents across the enterprise—including those embedded within software-as-a-service (SaaS) applications.

 

Enterprise agents can interact with shared systems, access sensitive data, initiate business workflows and potentially create or delegate work to other agents. Their purpose and permissions may change as models, prompts and workflows evolve. Some may continue operating after the business need that originally justified them has disappeared.

 

These realities raise fundamental lifecycle questions:

  • Who owns the agent, and who is accountable for its actions?
  • What business purpose justifies its existence?
  • Which systems and data can it access?
  • What happens when its model, workflow or responsibilities change?
  • How do we know it is still performing its intended task?
  • How quickly can we restrict or revoke its access if its behavior becomes unacceptable?

 

A registry that connects agents to their owners, purposes and permissions can help establish an authoritative view. But that view must extend across platforms rather than stopping at the boundaries of a single AI tool.

 

The challenge is particularly visible in complex environments such as healthcare and higher education. Acquisitions, legacy applications, overlapping responsibilities and multiple identity systems make it difficult to establish a single, accurate picture of access. A clinician may also be a researcher and department leader; a university user may be a faculty member, administrator or student across different contexts.

 

The solution requires shared governance across business units, supported by integrations that reduce manual reconciliation.

 

The takeaway: Treat AI agents as part of the enterprise identity and governance architecture, with accountable ownership, defined lifecycles and permissions that evolve as their purpose changes.

4. Authentication Is Not Authorization

 

A successful authentication establishes an identity. It does not automatically establish that the identity should be permitted to perform every subsequent action.

 

That distinction becomes especially important when AI agents can execute multiple steps, interact with external systems or combine individually permitted operations into an unacceptable outcome.

 

The discussion explored a practical framework for connecting approved access with what actually happens during execution:

 

DECLARE: Identify who is acting and why

 

Establish the agent or workload’s identity, accountable owner, business purpose and risk. Bring information from different agent platforms into a common view.

 

BOUND: Limit the authority

 

Define the agent’s permitted scope, credentials, approvals and prohibited actions. The boundaries must be explicit; simply describing an intended task does not necessarily define every action an agent should be allowed to take.

 

One implementation pattern discussed involved authenticating an agent and issuing short-lived tokens scoped to a particular endpoint and task. A lifetime of approximately five minutes was offered as an example, not a universal configuration.

 

Sharing a person’s password with an agent undermines the ability to distinguish and govern the agent’s authority.

 

ENFORCE: Control actions during execution

 

Runtime authorization asks whether an identity is permitted to perform a particular action at that moment, given the context and applicable policies.

 

The discussion also examined Model Context Protocol (MCP) and the need to understand which tools and endpoints agents can reach. Approved integration registries and gateways can help, but they cannot enforce policies over access paths that bypass them. Model guardrails alone should not be treated as a complete enterprise security control.

 

PROVE + ADAPT: Establish evidence and respond

 

Organizations need evidence linking the acting identity to its permissions, actions and the systems or data it touched.

 

Containment must also be more precise than simply switching an entire system off. As one participant observed, “The kill switch is not a binary switch.”

 

The goal is to stop harmful activity while avoiding unnecessary disruption to the business. Depending on the situation, that may mean revoking a credential, restricting access, stopping a specific action or isolating a workload.

 

The takeaway: Effective AI governance connects identity, purpose, authorization, runtime enforcement and evidence. Approval is only the beginning; organizations must be able to demonstrate what happened and respond when behavior falls outside approved boundaries.

Comments

I welcome your input on this article… please do that via the summary LinkedIn post on this same topic! 

5. Reduce Standing Privilege Where It Makes Sense

 

Just-in-time (JIT) access, just-enough privilege and zero standing privilege (ZSP) generated interest as ways to reduce persistent access.

 

The principle is straightforward: identities should receive the authority they need when they need it, for only as long as the task requires.

 

However, implementation is not equally easy everywhere. Temporary access may be more straightforward in modern cloud environments than in legacy systems where provisioning and revocation are more difficult.

 

Rather than treating zero standing privilege as an all-at-once transformation, organizations can begin with a bounded use case, demonstrate that temporary access works operationally and expand based on evidence.

 

The same principle applies to AI experimentation. Teams should be able to explore useful applications within defined boundaries, with stronger controls as agents begin interacting with production data or business-critical systems.

 

The takeaway: Start with a manageable use case, validate the operational model and reduce persistent privilege incrementally where the technology and business requirements support it.

6. AI Accountability Is a Business and Legal Issue

 

The legal discussion examined a question that cybersecurity leaders cannot ignore: Who is responsible when an AI system makes a mistake or takes an unauthorized action?

 

Increasing autonomy does not eliminate the responsibilities of the people and organizations that develop, integrate, deploy and use AI.

 

The discussion emphasized three important considerations:

 

  • AI is not a substitute for organizational accountability. The legal framework presented did not treat an AI agent as an independent legal person that automatically assumes responsibility for its actions.
  • “My AI did it” is not a complete defense. The presentation discussed emerging state-law restrictions on this argument for certain claims, while recognizing that legal outcomes depend on the facts and applicable law.
  • Responsibility may extend across the supply chain. Developers, deployers, integrators and other parties may have different obligations depending on their roles, contracts and the circumstances of an incident.The supply chain can be considerably longer than a simple relationship between a model provider and an enterprise customer. A model may be incorporated into a software vendor’s product, which is then deployed by an organization to support its own operations or serve its customers.

Contractual protections, liability provisions and opportunities to recover losses from upstream providers may vary substantially.

 

Insurance coverage is another area of uncertainty. Existing policies may not respond to every AI-related loss, and the terms, exclusions and pricing of dedicated AI coverage continue to evolve.

 

These are not merely theoretical concerns. They reinforce the need for security, legal, procurement and business teams to agree on intended use, acceptable boundaries, oversight responsibilities and the evidence needed to investigate an incident.

 

The takeaway: AI governance must address accountability across the entire technology and business ecosystem. Organizations should understand their own responsibilities rather than assume a vendor or insurance policy will absorb the consequences of an AI-related failure.

7. Revisit Vendor Contracts as AI Capabilities Change

 

AI functionality can materially change how a product processes information, interacts with other systems and uses customer data. Yet the contract governing that product may have been signed before those capabilities existed.

 

That gap deserves attention.

 

The discussion highlighted several areas for security, legal and procurement teams to examine when reviewing vendors that introduce or expand AI functionality.

 

Understand how data is used

 

Review whether contractual restrictions cover customer content, confidential information, metadata, derived information and operational signals.

 

Understand which providers receive the data and whether restrictions extend to downstream model providers.

 

Training and fine-tuning provisions deserve particular scrutiny. Broad rights to improve products and services may raise questions when vendors introduce new AI capabilities.

 

Define de-identification carefully

 

Removing obvious identifiers does not necessarily resolve every confidentiality concern. The meaning of de-identification, the standards applied and the possibility of re-identification all matter.

 

Ensure audit rights produce useful evidence

An audit clause is only as valuable as the evidence an organization can obtain and its ability to exercise that right. Direct inspection of model training may be restricted by intellectual-property and trade-secret concerns, making independent assurance reports a possible alternative where their scope and availability are appropriate.

 

Understand remediation obligations

 

If restricted information enters a model’s training process, straightforward deletion may not be possible. Remediation could require additional training, retiring a model version or other measures, depending on the technology and circumstances.

 

Preventive restrictions and clear response obligations are therefore important before data is used.

 

Before approving a vendor’s expanded AI functionality, organizations should ask:

 

  • What AI capabilities have been added since the agreement was signed?
  • Which additional providers receive customer or production data?
  • Do contractual restrictions cover training, fine-tuning, metadata and derived information?
  • What does de-identification mean under the agreement, and which obligations continue afterward?
  • What evidence can the organization obtain to verify compliance?
  • If restricted data is used or an agent causes harm, what notification, remediation, liability and insurance provisions apply?

These questions provide a starting point for internal review, not a substitute for legal advice or contract-specific analysis.

 

The takeaway: Vendor risk management must evolve alongside vendor capabilities. Security reviews and contracts should reflect how AI actually operates, not simply how the product worked when the agreement was signed.

Three Questions Every Security Leader Should Be Asking

The Boston discussion ultimately pointed toward three practical dimensions of identity and AI governance:

  1. Visibility: Do we truly know every identity in our environment?

Consider human identities, service accounts, workloads, credentials and AI agents. Establish what is covered, where gaps remain and who owns each identity.

 

  1. Control: What can each identity do, and are we applying least privilege?

Compare intended access with effective permissions. Identify unnecessary persistent authority, assess runtime controls and determine whether access can be safely restricted or revoked.

 

  1. Accountability: Who approved it, who owns it, who monitors it, and can we prove that chain?

Connect business purpose, approval, permissions, activity and response. Ensure that evidence is available to security, business, legal and procurement teams when needed.

 

A Practical Next Step

 

Rather than attempting to solve every identity and AI governance challenge at once, choose one important business workflow.

 

Trace the human and non-human identities involved. Confirm their owners and business purposes. Compare approved access with actual permissions, and test whether unnecessary authority can be removed safely.

 

Then review the relevant vendor’s AI functionality and data-use terms with legal and procurement colleagues.

 

This focused approach creates an opportunity to demonstrate progress, identify gaps and build a repeatable model for broader adoption.

 

The Path Forward: Build on What Already Works

 

The outlook for identity is improving, but progress will depend on sustained investment, integration and clear accountability.

 

AI can help organizations reduce the friction associated with identity implementation and analysis. It can also introduce new paths to sensitive systems and data, increase the speed of automated actions and complicate the assignment of responsibility.

 

The objective is not to slow innovation unnecessarily. It is to ensure that the enterprise can use AI effectively while maintaining control over identities, authority and outcomes.

 

That requires security leaders to look beyond authentication and inventory toward a more complete model of identity governance: one that connects who or what is acting, why it is acting, what it is permitted to do and how the organization will know when something goes wrong.

 

The Boston CxO Security Forum reinforced the value of addressing these questions through practical experience and candid peer exchange. The most useful progress may not come from another platform or sweeping transformation. It may begin with better integration, a clearly owned workflow and evidence that the controls in place are actually working.

 

Continuing the Conversation

 

The CxO Security Forum brings together senior cybersecurity, technology, identity, risk and compliance leaders for candid, peer-led discussions about the issues shaping enterprise security.

 

Thank you to our discussion leaders, Nicholas Farnsworth of Orrick, Herrington & Sutcliffe LLP and Swaroop Dhulpet of PwC, to Orrick for hosting, and to Western Alliance Bank and Ambient Security for supporting the community.

 

We also thank the participants who shared their experience and challenged assumptions under the Chatham House Rule. Discussion insights and quotations in this recap are presented without individual attribution.

 

Explore community materials: engagez.net/CxO

 

Learn more about the CxO Security Forum: cxosecurityforum.com

Comments

I welcome your input on this article… please do that via the summary LinkedIn post on this same topic!