A New Dallas Community, and a Conversation Worth Continuing

By Michael Hiskey

Lessons from the first DFW CxO Security Forum on identity, AI agents, and the access we keep giving away.

 

Last night, we held our first-ever DFW CxO Security Forum in Las Colinas, and it was a terrific way to launch the community in Dallas.

 

We gave away signed copies of George Finney’s Rise of the Machines: A Project Zero Trust Story. Although George couldn’t join us in person, we were fortunate to welcome John Kindervag, the creator of the Zero Trust strategy during his time as an analyst at Forrester and a leading voice in its continued evolution.

 

John’s thinking has helped shape how the cybersecurity community approaches access, trust, and risk. His latest book, Cyber Resilience at Machine Speed: The Zero Trust Model for the AI Era, extends those principles into a world increasingly shaped by artificial intelligence and automation. Several CISOs, CIOs, and senior leaders in the room agreed that his perspective remains among the most insightful in cybersecurity.

 

A special thank-you to Ambient Security for sponsoring the gathering and to Matthew Ulery, Chief Product Officer and Co-Founder, for bringing his considerable identity expertise into the conversation. The discussion was candid, occasionally argumentative, and frequently funny—which is exactly what the CxO Security Forum is designed to encourage.

 

Under the Chatham House Rule, participants were free to share experiences and challenge assumptions without their comments being attributed to them publicly.

 

Our central question was straightforward:

 

What can we see, control, and explain about the identities operating inside our organizations?

 

As the discussion unfolded, one theme became increasingly clear: Zero Trust depends on identity, but identity alone cannot determine whether an action should be allowed.

1. AI Is the Forcing Function for Zero Trust

 

I opened the discussion by suggesting that AI could turbocharge Zero Trust. John sharpened that idea with a memorable observation:

 

“AI is the forcing function to get people to adopt zero trust.”

 

The distinction matters.

 

Organizations have spent years discussing Zero Trust, often struggling to move beyond strategy documents and technology implementations. Now, AI agents are creating a more immediate reason to address the underlying issues.

 

An AI agent can take actions, invoke tools, access applications, and request permissions to accomplish a task. Its requirements may extend beyond what its creator initially anticipated. If an organization gives an agent broad credentials without defining the boundaries of its authority, it can accelerate existing security problems rather than solve them.

 

Matthew Ulery described the uncomfortable moment when an agent stops accessing only the resources an organization expected it to use and decides it needs something else.

 

Who evaluates that request? What policy governs the decision? Does the agent receive access automatically, or must a person approve it? How long should that access remain available?

 

These are not questions to answer after an agent has already acted. They belong in the design of the system.

 

AI makes Zero Trust more urgent because automated systems can operate at scale and speed, potentially exercising permissions in ways that are difficult to anticipate.  Organizations need a consistent way to evaluate every request, rather than assuming that an authenticated identity should be trusted to proceed.

2. All Digital Identities Are Non-Human Identities

 

I asked the room to estimate the ratio of non-human identities to human identities.

 

John declined to play along.

 

“All identities are non-human identities.”

 

He followed that with another line that got a laugh:

 

“No people have ever been on a network except in Tron.”

 

I walked straight into that one.

 

His point was more important than the joke. A digital identity is an assertion about who or what is behind an action. Networks see devices, traffic, credentials, and requests. They do not directly see the person sitting behind a keyboard.

 

An account labeled with an employee’s name does not guarantee that the intended person is controlling it. Nor does a successful authentication establish that the activity being requested should be permitted.

 

The same principle applies to service accounts, application identities, workloads, bots, and AI agents.

 

Organizations still need accurate inventories, clear ownership, and meaningful distinctions between employees and the systems operating on their behalf. But classification alone does not make an access decision.

 

As John put it:

 

“Identity is one of the many, many things that you look at before you make an access control decision.”

 

That statement captures the relationship between identity and Zero Trust.

 

Identity provides important context. It helps establish which actor is making a request and what attributes may be relevant. But the organization must also consider the resource being accessed, the requested action, the applicable policy, and the circumstances surrounding the request.

 

Zero Trust consumes identity as an input to a broader access decision. It does not stop at authentication.

3. Getting Through the Front Door Does Not Mean You Can Enter Every Room

 

Matthew offered a useful analogy. Showing your badge at the White House establishes something about who you are, but it does not give you permission to open every door in the building.

 

“That doesn’t mean you get to get in any door in the building you want to go to, right?”

 

The distinction between authentication and authorization is fundamental, yet organizations frequently devote more attention to proving identity than to controlling what an authenticated identity can actually do.

 

Consider a familiar onboarding practice. A new employee joins a team, and someone asks IT to copy the permissions of an existing employee in the same role. The request may be convenient, but nobody necessarily revisits whether the original employee needs every permission assigned to that account.

 

Over time, permissions accumulate. Temporary access becomes permanent. Exceptions become routine. The result is an environment in which access reflects historical decisions more than current business requirements.

 

Now apply that same practice to an AI agent operating with its creator’s full permissions.

 

An agent intended to help with a single task could inherit access to far more resources than it needs. If it can invoke additional tools or request further permissions, its effective reach may become difficult to predict.

 

Matthew’s guidance was direct:

 

“First of all, delegation. Second of all, just make sure everything is timebound.”

 

An agent helping you complete a task should not automatically become a permanent digital extension of your entire identity.

 

The organization needs to delegate a specific responsibility, define the permissions required, and establish when those permissions expire.

 

Zero Standing Privilege changes the equation

 

From my perspective, Ambient Security’s approach to identity—particularly Zero Standing Privilege supported by just-in-time access and just-enough privilege—is an important part of implementing a meaningful Zero Trust strategy.

 

The principle is straightforward:

 

  • Just enough privilege: Provide only the access necessary to complete the authorized task.
  • Just-in-time access: Make the required privilege available when it is needed.
  • Zero Standing Privilege: Reduce persistent, usable privileged access that remains available when no task requires it.
  • Time-bound authorization: Ensure access expires when its approved duration ends.

These principles are especially relevant to AI agents, but they also apply to administrators, employees, service accounts, and other identities.

 

Matthew also emphasized that understanding access requires business context. Discovering thousands of permissions is useful, but security teams need to know which resources matter most, which permissions create meaningful exposure, and which changes should take priority.

 

A massive inventory of access rights is not the end goal. The objective is to determine what should be removed, restricted, or granted temporarily—and to make those decisions operational.

4. Access Should Not Be a Badge of Honor

 

John shared a personal example involving a government security clearance process. He withdrew after asking whether he actually needed access to the protected data to perform the work. The answer was no.

 

His conclusion was simple:

 

“Don’t give anybody access to data they don’t need to get their job done.”

 

It sounds obvious. In practice, organizational culture often encourages the opposite.

 

More access can be perceived as a sign of seniority, importance, or trust. Broad permissions can make work easier in the short term. Removing them, however, raises a familiar question: what might break?

 

That concern can keep unnecessary access in place long after its original purpose has disappeared.

 

John described the resulting tradeoff memorably:

 

“You have a lot of highly compromised yet highly available networks, because no one cares whether they’re secure as long as they’re up.”

 

Availability matters, of course. But a system that continues to function is not necessarily a secure system, and operational success does not prove that its access controls are appropriate.

 

Organizations need to evaluate both.

 

This means examining whether identities have more privilege than necessary, whether access is still justified, and whether security exceptions have become permanent simply because nobody wants to risk disrupting a service.

 

For AI agents, the same principle applies. The fact that an agent can accomplish a task with broad access does not mean it should have that access.

 

The right question is not, “What permissions would make this agent most useful?”

 

It is, “What is the minimum authority this agent needs to accomplish its approved purpose?”

Comments

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

5. Just-in-Time Access: From Theory to Implementation

 

The discussion around just-in-time access was particularly valuable because participants did not agree on how widely it has been implemented or how difficult it can be to deploy across a large enterprise.

 

That disagreement made room for a practical example.

 

An executive from a major pharmaceutical company and Ambient Security client described an initiative to improve privileged access management for Windows and Linux infrastructure.

 

The organization was beginning to separate an administrator’s eligibility for access from the activation of that access.

 

As the executive explained:

 

“I’m being assigned the privilege, but I cannot use it.”

 

In other words, the administrator may be authorized to request privileged access, but that does not mean the privilege is continuously available for use.

 

Activation requires approval, with dual approval for the highly privileged access described during the discussion. The privileged access management solution then brokers the session.

 

As the executive put it:

 

“I won’t even need the password for that system administrator.”

 

The rollout was still underway, but the example illustrated how Zero Standing Privilege can become an operational practice rather than an abstract objective.

 

Being eligible to administer a system should not mean carrying usable administrative privileges around all day.

 

The distinction is important because persistent privilege creates opportunities for misuse, whether through compromised credentials, malicious insiders, or automated systems that obtain access they should not have.

 

Just-in-time access provides a mechanism for reducing that exposure. The organization grants access when the task requires it, applies the appropriate approval process, and removes the privilege when the authorized period ends.

 

The essential question is what remains available afterward.

 

If privileged access is activated for a specific task, it should not silently become another permanent permission in an already complicated environment.

6. Are We Looking Where the Light Is Better?

 

John introduced the streetlight effect: the tendency to search where it is easiest to look rather than where the missing object actually is.

 

His cybersecurity version was particularly memorable:

 

“But if it doesn’t come in the logs, well, then it must not exist.”

 

That observation applies to many security programs.

 

An organization may have excellent visibility into one directory, one network boundary, or one privileged access platform. That visibility can create a false sense of confidence if other applications, cloud permissions, service accounts, or delegated agent actions remain outside the picture.

 

What the organization can see is not necessarily the whole environment.

 

This is particularly relevant as AI agents connect systems and invoke tools across different platforms. Access relationships may span multiple identities, applications, services, and permissions. Understanding the resulting exposure requires more than looking at a single log source or directory.

 

Mapping those relationships can help identify potential paths to sensitive resources. But a map is only useful if it helps leaders make better decisions.

 

A large graph showing thousands of identities and permissions may be technically impressive without telling a security team what to do next.

 

Business context is essential.

 

Which resource does a particular access path reach? How sensitive is the information? What privileges could an attacker or compromised agent obtain? What would happen if the permission were removed? Which change would meaningfully reduce exposure without disrupting an essential business process?

 

Visibility is the starting point. Prioritization and action turn visibility into protection.

7. Security Policy Has to Do Something

 

John repeatedly returned to the policy actually enforced by a control, rather than the policy documented in a presentation or written in a governance manual.

 

His most provocative formulation was:

 

“All bad things happen inside of an allow rule.”

 

The point is that an attacker does not necessarily need to bypass a control if the existing rules already permit the activity.

 

A connection may be technically authorized while still creating unacceptable risk. A user may have legitimate credentials but attempt an action that falls outside the user’s responsibilities. An AI agent may be operating exactly as configured while exercising permissions that should never have been granted in the first place.

 

The challenge is to examine what the organization allows—and to question the assumptions behind those permissions.

 

Some rules were established years ago. Others were created to accommodate a temporary business need. Some reflect a deliberate risk decision, while others may simply have survived because nobody reviewed them.

 

John also used a terrain analogy to explain how organizations should approach Zero Trust. Security teams cannot control everything that influences their environments, but they can identify the critical resources they must protect and concentrate their efforts there.

 

This is the purpose of defining a protect surface: identifying the critical assets, data, applications, services, and processes that require deliberate protection.

 

Organizations cannot control every emerging AI model, vulnerability, or attacker. They can, however, make explicit decisions about which interactions their critical resources permit.

 

Those decisions need to be translated into enforceable policies.

 

A Zero Trust strategy is not complete because an organization has adopted an identity platform or documented an access policy. It must be reflected in the controls that determine whether a particular request is allowed, denied, or subjected to additional verification.

8. AI May Finally Make the Business Case for Better Security Hygiene

 

The discussion also touched on PHP2Shell, including questions about disclosure and response speed. Those concerns fed into a broader issue: can the business enthusiasm surrounding AI help fund the foundational security work that organizations have repeatedly deferred?

 

Identity inventories, permission reviews, access governance, and legacy cleanup are not always the most exciting projects to present to executive leadership.

 

Yet these capabilities become more important as organizations deploy agents that can interact with systems, retrieve data, and initiate actions at scale.

 

If the business wants AI agents to operate safely, then ownership, scoped authority, and enforceable access controls are part of delivering that capability.

 

They are not optional extras to be considered after deployment.

 

AI can provide a stronger business justification for addressing longstanding identity weaknesses. Organizations need to understand what their agents can access, which privileges they require, and how to limit their authority without undermining their usefulness.

 

The same investment can improve security for human users, administrators, applications, and other non-human identities.

 

The opportunity is to stop treating identity hygiene as an isolated technical cleanup project and recognize it as a prerequisite for responsible automation.

 

What Security Leaders Should Take Back to Work

 

The DFW discussion left me with several practical questions that security leaders can use to evaluate their own environments.

 

  1. Can you account for the identities operating in your environment?

Inventory employees, administrators, service accounts, workloads, and AI agents. Establish clear ownership and understand how these identities interact with critical resources.

 

  1. Do you evaluate authorization separately from authentication?

A successfully authenticated identity should not receive automatic permission to perform every requested action. Access decisions must reflect the resource, the action, and the applicable policy.

 

  1. Are privileged permissions continuously available?

Identify where administrators and other identities retain standing privileges. Determine which permissions can be replaced with just-in-time access and just-enough privilege.

 

  1. Are agent permissions scoped and time-bound?

Agents should receive only the authority required for their approved tasks. Define how access requests are evaluated, when human approval is required, and how permissions are revoked.

 

  1. Can you see the access paths that matter?

Look beyond the systems that generate the most convenient logs. Evaluate visibility across applications, cloud environments, directories, service accounts, and delegated agent actions.

 

  1. Do your policies actually constrain behavior?

Review the allow rules that govern access to critical resources. Determine whether they reflect current business requirements or simply preserve historical permissions.

 

  1. Can you explain which risks matter most?

Use business context to prioritize access relationships and permissions. Focus on the paths that create meaningful exposure rather than treating every finding as equally urgent.

 

These questions are useful whether an organization is deploying its first AI agents or already managing extensive automation across its enterprise.

 

The Question That Matters Most

 

The DFW CxO Security Forum was a strong start for a new community. The value came not just from hearing experienced practitioners discuss Zero Trust, but from seeing where their perspectives aligned, where they disagreed, and how those differences led to more practical questions.

 

My thanks to John Kindervag for challenging our assumptions, Matthew Ulery for contributing his identity expertise, Ambient Security for sponsoring the gathering, and all the executives who helped make the conversation candid and worthwhile.

 

For me, the most important takeaway is that AI is making the limitations of traditional access practices harder to ignore.

 

We cannot assume that an authenticated identity should be trusted to proceed. We cannot treat inherited permissions as proof of need. We cannot rely on visibility into one part of an environment to establish that we understand the whole. And we cannot expect written policies to protect resources if the controls themselves permit the wrong actions.

 

Zero Trust requires us to examine the context of every access decision and enforce the boundaries that matter.

 

Identity is essential to that process. But identity is only one part of the answer.

 

The question I would take back to any security team is this:

 

If a compromised account—or a perfectly authenticated AI agent—tries to do something it should not, what actually stops it?

 

That is a conversation worth having with your team.

 

And it is a conversation we will continue at the CxO Security Forum.

Comments

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