Your AI Agent Has an Owner. Does It Have an Expiration Date?

By Michael Hiskey

As healthcare organizations accelerate their adoption of AI, security leaders are confronting a familiar challenge in a new form: how do you govern identities, manage access, and remain accountable for systems that can act on their own? At the Health-ISAC Dallas Executive Forum, one practical idea stood out: every AI agent should have two owners, a regular recertification schedule, and an expiration date.

 

The Question AI Security Leaders Should Be Asking

 

The familiar line captures something important about experience: knowledge has value, and losing track of who holds it can create real problems. In cybersecurity, the same principle applies to the accounts, credentials, processes, and increasingly autonomous systems that organizations depend on every day.

 

At the Health-ISAC Dallas Executive Forum, a conversation about artificial intelligence kept returning to very human questions: ownership, judgment, and accountability when things go wrong.

 

One of the most useful ideas discussed was surprisingly straightforward: assign every AI agent a primary owner and an alternate owner, require periodic recertification, and make someone explicitly decide whether the agent still needs to exist.

 

I kept coming back to that idea.

 

Organizations spend considerable time evaluating what AI agents can do. But how often do we ask who will remain responsible for those agents three years from now? Who knows what they can access? Who understands why they were created? And what happens when the person who built one leaves the organization?

 

Those questions framed one of the most valuable discussions at our Executive Forum, where healthcare security and technology leaders shared experiences spanning care delivery, healthcare technology, and services. The discussion moved beyond theoretical AI capabilities into the operational realities of identity management, data governance, vendor oversight, and security automation.

 

The central lesson was clear: AI is exposing foundational security and governance weaknesses that many organizations have struggled with for years.

1. AI Is Exposing Long-Standing Identity Problems

 

Identity security remains one of the most significant challenges facing enterprise security teams. The introduction of AI agents adds another layer of complexity to an environment that may already contain legacy accounts, inconsistent access policies, and poorly understood permissions.

 

During the discussion, participants questioned the reliability of controls they once trusted.

 

Active Directory was one example. A participant described having less confidence in it than they had less than two years earlier, particularly when considering the complexity of an environment that includes numerous systems outside the traditional directory structure.

 

Multifactor authentication was another area of concern. Adversary-in-the-middle attacks have demonstrated the limitations of older authentication methods, especially SMS-based verification. Simply having an MFA policy does not guarantee that an organization is adequately protected.

 

The larger problem is the gap between written policy and operational reality.

 

Organizations may believe they have appropriate access controls in place, only to discover during an identity assessment that thousands of accounts have compromised passwords, excessive privileges, or risky capabilities. Service principals and other non-human identities may exist without a clear record of who created them or why they remain active.

 

AI does not create these weaknesses. It can make them more consequential by introducing additional identities, permissions, and automated actions into environments that already lack complete visibility.

 

Before organizations can safely expand AI adoption, they need to understand what identities exist, what those identities can access, and who is accountable for them.

2. Non-Human Identities Need Owners—and Expiration Dates

 

The growth of non-human identities was one of the most important themes of the Forum.

 

Service accounts, application credentials, API tokens, bearer tokens, ephemeral cloud credentials, robotic process automation (RPA), and AI agents all need some form of identity and access. As these systems multiply, organizations can lose track of their relationships, permissions, and intended purposes.

 

During the discussion, I referenced a Palo Alto estimate of 109 non-human identities for every human identity. Whatever the exact ratio in a particular environment, the scale of the challenge is significant.

 

Consider what happens when a developer creates a token for an application. The token may become embedded in a workflow, connected to another service, or used by a process that operates continuously. If the developer leaves, the organization may lose the only person who understands where that token is used.

 

The credential remains. The access remains. The documentation may never have existed.

 

This is how temporary solutions become permanent security liabilities.

 

A practical model: two owners and mandatory recertification

 

One participant described an approach that directly addresses this problem. In that organization, non-human identities have assigned owners, and robotic process automation identities are registered and tied to the applications they support.

 

AI agents receive both a primary owner and an alternate owner. They must be registered, certified, and periodically reviewed.

 

The recertification schedule depends on the agent’s purpose and activities. Periods discussed included three months, six months, and one year.

 

If the agent is not renewed, its authorization expires.

 

I described this as an automatic “die date” for an agent: a defined point at which it must be actively justified to continue operating.

 

Among roughly 30 CISOs I had asked about this type of lifecycle control, this was the first organization to describe such a structured approach.

 

The idea is not entirely new. Organizations learned similar lessons from service accounts that remained active for years—or even a decade—after their original purpose had been forgotten. Multiple owners, documented provenance, and periodic certification are ways to prevent that history from repeating itself with AI.

 

The principle is simple: an identity should not remain active indefinitely just because nobody has taken responsibility for turning it off.

 

Inventory is part of the answer

 

Some organizations are already assigning ownership to non-human identities. Others are still working toward comprehensive inventories and using configuration management databases to improve visibility.

 

The challenge is particularly difficult in mature environments with decades of accumulated technology. Legacy accounts may have ambiguous names, incomplete records, or permissions that no longer correspond to an employee’s current role.

 

A sustainable AI governance program cannot exist independently of this underlying identity cleanup.

 

Organizations need to know what they have before they can govern it effectively.

3. Healthcare Organizations Are Taking a Deliberate Approach to AI

 

Healthcare introduces additional considerations because security decisions can affect clinical workflows and patient care.

 

Participants described a cautious approach to deploying agents, particularly when systems interact with sensitive patient information or operational environments.

 

One organization initially restricted access to large-scale agent development environments and later adopted an entitlement model. Employees cannot simply enter a broad agent-development environment without authorization. Personal, knowledge-oriented agents are treated more permissively, but certification remains part of maintaining a clean and manageable environment.

 

The distinction matters. Organizations want employees to benefit from AI, but they also need to prevent uncontrolled proliferation of agents, credentials, and data connections.

 

Participants emphasized that healthcare delivery organizations are not necessarily operating like technology startups racing to capture market share. They expect AI to change workflows and workloads, but they want to apply lessons learned before permitting unrestricted deployment.

 

That caution is particularly relevant where an AI agent might retrieve patient information, interact with clinical applications, or initiate actions that affect care.

 

Agents must not inherit their creators’ access

 

A practical example involved an intern who created an agent to retrieve information.

 

The appropriate approach is to give the agent documented access to the resources required for its task. It should not simply operate using the intern’s personal credentials.

 

This distinction is fundamental to identity governance. When an agent inherits a human user’s permissions, it can become difficult to determine which actions were taken by the person and which were performed by the agent. It can also give automated systems access beyond what their specific functions require.

 

AI agents need their own identities, defined permissions, accountable owners, and appropriate monitoring.

 

The same principle applies to existing service accounts and legacy identities. Organizations must address historical access problems while establishing controls for the next generation of automated systems.

4. Identity Assessments Can Reveal Problems That Routine Controls Miss

 

One example shared during the Forum illustrated how deeply embedded identity weaknesses can become.

 

A participant described a fintech organization conducting autonomous penetration testing. The test identified a newly created account with domain-administrator privileges—an alarming level of access for a new user.

 

Further investigation revealed a lengthy attack path through Active Directory. The account belonged to a group it should never have been permitted to join, and the account had been used to obtain password hashes.

 

The root cause was not simply a sophisticated attack. It was a flawed onboarding workflow.

 

New hires entered a holding group until their official roles were assigned. Hiring managers did not always complete that process correctly. Rather than risk blocking employees from doing their jobs, the default outcome granted additional access.

 

A workflow intended to make onboarding easier had created a serious security weakness.

 

The investigation also uncovered a suspected North Korean IT worker whose identity did not match the photograph associated with the team account. The organization provided its penetration-testing findings and supporting evidence to the FBI and changed its onboarding procedures, particularly its role-assignment process.

 

The discussion also included another example of a candidate who answered technical interview questions convincingly but raised concerns because of unusual behavior during the interview. A subsequent reference check with Oracle indicated that the candidate had not worked there as claimed.

 

These examples reinforce an important point: sophisticated security tools cannot compensate for broken identity processes.

 

AI adoption makes it even more important to validate identities, assign appropriate permissions, and ensure that access is granted according to verified roles rather than operational convenience.

Comments

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

5. Human Oversight Remains Essential—but It Has Limits

 

The Forum surfaced a difficult question: should AI agents be permitted to act autonomously, or should a human approve every consequential action?

 

Most healthcare participants favored a human-in-the-loop approach. Their organizations do not permit agents to independently choose and execute consequential actions without human involvement.

 

That is understandable in environments where an automated decision could interrupt clinical operations, expose sensitive information, or affect patient care.

 

For example, one participant described AI-supported analysis in prior authorization. AI can help analyze information and support decision-making, but a human must make the final determination. The organization does not want AI independently authorizing procedures.

 

However, there is another side to the debate.

 

Cyber attackers operate at machine speed. If defensive systems require human approval for every action, security teams may struggle to respond quickly enough to evolving threats.

 

A solution-provider participant argued for automating as much of cyber defense as possible. Another participant suggested that human review might be reduced over time as systems demonstrate that the probability of harmful outcomes is sufficiently low. In some situations, reviewing exceptions or sampling transactions could eventually replace universal approval.

 

The challenge is determining where that transition is safe.

 

Healthcare changes the risk calculation

 

In a healthcare environment, an anomalous event does not automatically indicate malicious activity.

 

An ICU system or other patient-care environment may generate telemetry that appears unusual compared with normal enterprise activity. Automatically suspending an account or interrupting a process might seem appropriate from a cybersecurity perspective but could create a patient-safety issue.

 

Healthcare organizations also need emergency access procedures, often described as “break the glass,” that allow clinicians to obtain necessary access when routine authentication processes would otherwise interfere with care.

 

These realities make data quality, contextual awareness, and carefully tested response procedures essential.

 

Participants identified opportunities to automate limited, lower-risk actions while keeping people focused on critical workloads. They also acknowledged that current SIEM capabilities and underlying data may not be mature enough to support highly effective machine-to-machine action across complex healthcare environments.

 

The goal should not be automation for its own sake. It should be to reduce risk while preserving the availability and safety of essential services.

6. Can Organizations Actually Stop an AI Agent?

 

The conversation about autonomy led to another practical question: if an AI agent begins taking undesirable actions, can an organization reliably stop it?

 

Participants discussed AI gateways, endpoint controls, and network telemetry as potential control points.

 

One view was that AI gateways, combined with endpoint protection capable of identifying AI-related threats, could eventually provide a way to monitor or constrain third-party and agent-based activity.

 

Another participant drew on experience in the oil and gas sector, where connecting endpoint and network telemetry can help identify a compromised endpoint and stop a process. The same methodology could potentially be applied to AI-related activity, although the participant had not yet tested that approach.

 

These are promising directions, but they should not be confused with proven, universal controls.

 

The group questioned whether a master switch exists that can reliably terminate an agent in the middle of an operation. One participant cautioned that some proposed solutions are capabilities organizations would like to have rather than controls they can confidently deploy today.

 

Agent identity also remains an area of concern. Participants questioned whether agents can be strongly bound to trusted identities in the same way as other enterprise systems, including through certificate-based mechanisms.

 

Without reliable identity binding, monitoring, and termination capabilities, organizations may struggle to establish that an agent is trusted—or to intervene when it behaves unexpectedly.

 

These questions need to be answered through implementation, testing, and validation, not simply through vendor assurances.

7. Third-Party AI Creates a Visibility and Contractual Challenge

 

Organizations can establish internal rules for AI use, but third-party AI introduces a different problem: customers may have limited visibility into what vendors are doing inside their own environments.

 

A vendor may incorporate external models, open-source components, or new AI capabilities without providing customers with a complete understanding of how those components work or what risks they introduce.

 

The Forum discussion highlighted the speed at which vendors are adopting AI. Startups racing to market may incorporate open-source models without sufficient due diligence. In some cases, the vendor itself may not know whether the model contains vulnerabilities or backdoors.

 

Customers then inherit risk they cannot easily evaluate.

 

This is not entirely new. Organizations have long struggled with vendor transparency, supply-chain risk, and the limits of third-party assessments. AI increases the stakes because models and capabilities can change quickly, while customers may have little ability to inspect the underlying systems.

 

Questionnaires are not a substitute for enforceable obligations

 

Participants discussed restrictions on vendors using customer data to train AI models. Some organizations prohibit training on their data, while others update their contractual language during renewal negotiations.

 

Healthcare agreements and business associate agreements may already restrict certain uses and disclosures of protected information. Depending on the circumstances, using identifiable information for unauthorized model training or sharing it with others could violate existing contractual obligations.

 

However, contractual language does not eliminate the visibility problem.

 

Customers may be unable to independently verify every action a vendor takes within its own environment. An organization may prohibit certain data uses but still have difficulty detecting whether those restrictions are being followed.

 

The group also considered whether vendors might use aggregated or anonymized information to improve models. Participants noted that some organizations prohibit such uses today, while acknowledging the difficulty of detecting them.

 

During the discussion, I referenced a presentation by Brian Kelly of Connecticut Health that introduced a “TPRAI” approach involving seven questions for vendors. The response from the group was practical: vendor answers matter only when the commitments become meaningful contractual obligations.

 

Security questionnaires can help organizations understand vendor practices, but they cannot replace enforceable terms, ongoing oversight, and clear accountability.

 

Watch for expanding vendor data rights

 

Participants also expressed concern about increasingly aggressive vendor contract language, particularly provisions that grant broad rights over customer data or give vendors considerable discretion to change products and services.

 

Organizations need to examine these terms carefully, especially when dealing with established vendors that already hold significant amounts of sensitive information.

 

The questions are not limited to whether a vendor uses AI. They include what data it can access, how that data can be used, which third parties are involved, whether the underlying models can change, and what happens when the contractual relationship ends.

 

AI governance must extend beyond internal systems to the entire vendor ecosystem.

8. Deception Tokens May Help Detect Unwanted AI Behavior

 

One participant introduced another potential safeguard: AI deception tokens.The concept resembles a canary token or honeypot. An organization places a carefully controlled token within an environment, where an AI system might encounter it while attempting to achieve an objective.

 

If the token is accessed or used unexpectedly, it can provide an indication that the system has moved beyond its intended boundaries.

 

The idea is particularly interesting in environments where organizations cannot fully inspect a third-party model or independently verify every aspect of its behavior.

 

Rather than relying exclusively on knowing which model a vendor uses, deception tokens offer a potential way to detect certain forms of unwanted interaction.

 

The underlying observation was that AI systems may seek the shortest path to completing a task. If that path leads to a resource the agent should never access, a well-designed deception mechanism could help reveal the problem.

 

Such controls are not a replacement for access restrictions, monitoring, or governance. They are another possible layer of defense that organizations can evaluate as their AI environments evolve.

 

9. AI Is Only as Reliable as Its Data and Guardrails

 

The Forum also explored whether today’s AI systems should be treated as genuinely intelligent or as powerful tools for pattern recognition, computation, and discovery.

 

Participants did not need to resolve that philosophical question to agree on a practical point: AI-generated outputs require verification.

 

A model may produce a convincing answer that is incorrect. It may invent a product, make an unsupported recommendation, or present a conclusion without a reliable basis.

 

During the discussion, I shared examples of ChatGPT suggesting that my daughter had a walnut allergy and inventing faucet products that did not exist.

 

The point was not that AI lacks value. It was that plausible-sounding output is not proof.

 

Model performance depends on the quality of its data, the design of its guardrails, and the context in which it operates. Even apparently significant mathematical or technical results may require substantial human effort to verify.

 

Organizations should apply the same discipline to AI-generated decisions that they apply to other consequential systems: establish boundaries, validate results, and ensure that the level of oversight matches the potential impact.

 

For healthcare organizations, that means being particularly careful about applications involving patient information, clinical decisions, or operational processes where an incorrect action could have serious consequences.

 

10. Security Teams Must Enable AI Safely

 

One of the most useful observations from the Forum was that security teams cannot simply become the “Department of No.”

 

Employees want to use AI tools. They see opportunities to save time, automate repetitive work, and improve productivity. Telling them that AI is prohibited without offering a workable alternative may push activity into environments that security teams cannot monitor.

 

But unrestricted adoption creates its own problems.

 

I described an example involving a sales representative who created 600 client dossiers, each approximately 35 pages long, and automated an email campaign using Claude and Cohere. Beyond the cost and questionable effectiveness of the effort, the example raised broader questions about how employees select tools, process data, and deploy automation without appropriate oversight.

 

Another participant described a clinician entering patient information into Claude, prompting concerns about personally identifiable information and data handling.

 

These examples illustrate why governance needs to be practical and accessible.

 

Organizations should understand what employees are trying to accomplish, identify the appropriate tools and permissions, and establish clear rules for acceptable use. They also need to consider data classification, privacy, contractual obligations, costs, and the possibility that automated activity will create large volumes of low-value output.

 

The objective is to move toward “yes” by making safe AI use possible—not to approve everything, and not to prohibit everything.

 

Practical Takeaways for Security Leaders

 

The discussion at the Health-ISAC Dallas Executive Forum produced several actionable lessons for organizations evaluating AI adoption.

 

  1. Inventory your non-human identities. Identify service accounts, application credentials, tokens, bots, RPA processes, and AI agents. Document their purpose, permissions, dependencies, and lifecycle.
  2. Assign a primary and alternate owner. Every agent should have identifiable people responsible for its continued operation. Ownership should survive employee departures and organizational changes.
  3. Establish expiration and recertification requirements. Define review periods according to an agent’s purpose and risk. Require explicit renewal rather than allowing identities to remain active indefinitely.
  4. Give agents their own identities and least-privilege access. Do not allow an agent to inherit a creator’s personal credentials simply because doing so is convenient.
  5. Fix identity and onboarding weaknesses. Validate roles, eliminate excessive default permissions, and investigate legacy accounts that have unclear purposes or ownership.
  6. Match autonomy to risk. Start with well-defined, lower-risk workflows. Require human approval where the consequences of an incorrect action are significant, and test automated responses before expanding their authority.
  7. Validate the ability to intervene. Determine whether your organization can detect unexpected agent behavior, restrict its access, and terminate activity. Treat proposed controls as unproven until they have been tested.
  8. Extend AI governance to vendors. Review data-use restrictions, model dependencies, contractual rights, third-party access, and change-management obligations. Make important commitments enforceable.
  9. Build governance that supports responsible adoption. Provide approved tools, clear rules, and practical alternatives so employees can use AI without creating unmanaged security and privacy risks.
  10. Keep foundational data governance in focus. AI does not eliminate the need for accurate inventories, reliable data, sound access policies, and accountable ownership. It makes these fundamentals more important.

 

Looking Ahead: Liability, Contracts, and Post-Quantum Security

 

The conversation also identified several areas worth exploring in future Executive Forums.

 

One is liability for actions taken by non-human identities and AI systems. I recently heard an attorney compare AI liability with automotive liability, raising difficult questions about how customers might prove that a particular model caused a specific outcome.

 

Another is post-quantum encryption. As quantum computing advances, organizations will need to understand the implications for their cryptographic infrastructure and prepare for the transition to quantum-resistant approaches.

 

Vendor contract management was another suggested topic, particularly as providers seek broader rights over data and greater flexibility to change their products.

 

We also discussed whether large healthcare organizations, including Mayo Clinic, might offer useful lessons on negotiating AI contract terms and data protections at scale.

 

These are not isolated legal or technical issues. They are part of the broader challenge of governing systems that are becoming more capable, more interconnected, and harder to observe.

 

The Bottom Line: Every Agent Needs Accountability

 

One participant summed up the value of the discussion by emphasizing the importance of practical controls over broad AI claims. Much of what is presented as a new AI governance challenge, the participant observed, is an extension of problems organizations have struggled to solve in data governance and foundational security.

 

That observation resonated with me.

 

The Forum was valuable because participants shared real approaches, acknowledged unfinished work, and challenged assumptions without shutting down the conversation. They did not pretend every problem had a ready-made solution.

 

We also returned to a question that should guide the next phase of enterprise AI adoption: how do organizations enable innovation without losing control of the systems they deploy?

 

For me, the answer begins with accountability.

 

An AI agent should have a documented purpose, appropriate permissions, a primary owner, an alternate owner, and a defined review date. Its continued existence should depend on someone affirmatively deciding that it is still needed.

 

That may sound simple compared with the more ambitious promises surrounding artificial intelligence. But the organizations that establish these fundamentals now will be better positioned to manage the complexity that follows.

 

My thanks to Linda (Tassinari) Joseph, Katherine Zavala, and the Health-ISAC team for making these gatherings possible, and to everyone who contributed openly to the discussion. Linda also helped bring the group back to the issues members want to explore next, including vendor contracts and post-quantum preparation.

 

This is how I hope the Executive Forums continue to grow: extending the work of the summits, bringing leaders together around the problems they are actually facing, and returning their experiences and questions to the broader community.

 

I am grateful to everyone who made time to participate and speak candidly.

 

And I am still thinking about those two owners—and that renewal date.

 

Because an AI agent may have an owner today. The real test is whether someone will still be accountable for it tomorrow.

Comments

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