Trust Is Not a Permanent Permission

Trust has always been essential to the way we organize the world. We rely on people and institutions to make decisions, exchange information and carry out activities we cannot manage alone.

The digital world developed mechanisms to achieve much the same thing. We assign identities to users, register devices and authorize applications to communicate with other systems. These arrangements allow millions of interactions to take place without requiring a human decision every time.

For years, much of this activity occurred within environments that organizations could reasonably understand and control. Today, those boundaries are becoming harder to define. Cloud services communicate across organizational networks, while applications exchange sensitive information through automated interfaces. Machines increasingly authenticate other machines, and AI-enabled systems are beginning to carry out complex tasks with limited human intervention.

We have built an extraordinary infrastructure for establishing digital trust. I am less certain that we have developed an equally effective approach to deciding when that trust should change.

When trust becomes an assumption

Digital systems need reliable ways to establish identity. Cryptographic credentials and authentication protocols provide much of the foundation for secure communication. But an identity that was legitimate yesterday does not necessarily justify every action taken under that identity tomorrow.

Consider a service account created to connect two business applications. Initially, it receives access to a limited set of information. Over time, additional permissions are granted to support new functions. The application evolves, responsibilities shift and the account continues operating. Years later, it may retain access that nobody remembers authorizing and that the current system no longer needs.

In this scenario, authentication may be working exactly as intended. The credentials remain valid, the connection is encrypted and the activity is technically permitted. The risk comes from assuming that authority granted in the past remains appropriate indefinitely.

Legitimate access can gradually become excessive access without a single obvious security incident marking the transition.

The difference between identity and authority

Proving that a system is what it claims to be is essential, but it is only part of the security decision.

An authenticated application may be authorized to retrieve specific customer records. That does not mean it should be able to export an entire database. Similarly, a recognized industrial device may legitimately communicate with a control system without every command it sends being appropriate.

The distinction is between establishing identity and defining the authority associated with it.

This is where Zero Trust offers an important shift in thinking. Rather than relying on implicit trust based on network location or a previously established connection, access decisions should reflect the purpose of the interaction and the conditions under which it occurs.

In practice, this requires more than authentication. Organizations need architectures capable of enforcing meaningful boundaries and reconsidering access when circumstances change.

Zero Trust is sometimes interpreted as an absence of trust. I see it differently. It is an attempt to make trust more precise.

When the machine becomes the workforce

Organizations have traditionally designed identity and access policies around people. Employees join an organization, change responsibilities and eventually leave. Their permissions can be reviewed against relatively familiar roles.

The growing population of non-human identities presents a different challenge.

Automated processes may operate continuously, communicating across systems that no single team fully controls. Some machine identities remain active for years. Others exist only briefly as software workloads are created and removed. Their authority can be extensive even when responsibility for governing them is unclear.

AI agents make this issue particularly interesting.

Imagine an AI assistant authorized to help a finance team prepare a quarterly report. It retrieves financial data and analyzes the results before preparing a draft for management. During that process, it discovers an inconsistency and decides to correct the underlying accounting record.

The action may appear reasonable. It might even improve the accuracy of the report.

But was the agent authorized to change the source data?

That is a fundamentally different question from whether the agent successfully authenticated to the accounting system.

An AI agent may use legitimate credentials and approved tools while attempting an action beyond the authority intended by its operator. This is why technical access controls must remain effective even when an automated system can independently determine how to complete an assigned task.

The more autonomy we introduce, the more important it becomes to distinguish between permission to pursue an objective and authority to take any action that might help achieve it.

The quantum dimension

There is another reason to reconsider how digital trust is established and maintained.

Much of today’s digital identity infrastructure relies on public-key cryptography. Digital certificates help systems establish authenticated relationships, while cryptographic signatures and key-establishment mechanisms support secure communication.

A sufficiently capable cryptographically relevant quantum computer could undermine widely deployed public-key algorithms that were not designed to resist such attacks.

Post-quantum cryptography addresses this particular threat by introducing cryptographic mechanisms designed to withstand attacks from both classical and quantum computers. But adopting new algorithms does not resolve the broader challenge of digital trust.

Organizations must still understand how credentials are issued and managed. They need to know which systems depend on particular cryptographic mechanisms and whether those dependencies can be updated as requirements evolve.

This becomes especially difficult with long-lived devices and embedded systems. Equipment designed to operate for decades may rely on cryptographic technologies that eventually need replacement, even when the equipment itself remains functional.

Changing a certificate or algorithm may be straightforward in one part of the infrastructure and extraordinarily difficult in another.

The quantum transition therefore reinforces an architectural lesson that extends beyond cryptography: security mechanisms must be capable of evolving without requiring every connected system to be rebuilt.

Strong cryptography helps establish trustworthy identities and protect communications. Authorization determines what those identities are permitted to do.

Neither can substitute for the other.

Trust must remain revocable

The principle of limiting access to what is necessary is hardly new. What is changing is the scale of the systems to which it must be applied.

A machine identity may need permission to retrieve information from a particular service. That permission should reflect its actual purpose rather than the broadest access technically available.

Some activities can proceed automatically within established boundaries. More sensitive actions may justify additional verification or human approval. The appropriate controls depend on the consequences of the action and the operational environment.

Equally important is the ability to change those boundaries.

Organizations should be able to review permissions and restrict access when a service changes or a device is compromised. Credentials need to be manageable so that security teams can respond without unnecessarily disrupting legitimate operations.

Of course, not every environment can support continuous reauthorization or immediate interruption. Industrial systems and other critical services may require carefully engineered controls that preserve safety and availability.

The objective is not to make legitimate activity unnecessarily difficult. It is to avoid designing systems in which permission, once granted, becomes almost impossible to withdraw.

Trust without a practical mechanism for reassessment eventually becomes an assumption.

Start with one identity nobody thinks about

For organizations looking to make this problem tangible, I would begin with a non-human identity that supports an important business function.

Choose a service account or machine credential that operates regularly but rarely attracts attention.

Find out who is responsible for it and what business function it serves. Examine the systems it can reach, then compare its current permissions with what it actually needs to accomplish.

Next, look at how the relationship is maintained.

Does anyone periodically review its access? Could its credentials be rotated without disrupting operations? If the identity were compromised, how quickly could the organization restrict its authority?

Finally, determine whether the cryptographic mechanisms supporting that identity can be updated when security requirements change.

The exercise may reveal a well-governed relationship. It may also uncover credentials that have outlived their original purpose or permissions that have accumulated without meaningful review.

Neither finding requires a quantum computer or an autonomous AI agent to become relevant. These are risks that exist today, and addressing them creates a stronger foundation for a future in which more systems will act on our behalf.

Trust that remains under control

We need digital trust. Without it, the connected world would struggle to function.

But the nature of the systems we trust is changing.

Quantum computing challenges some of the cryptographic foundations of digital identity. AI-driven automation raises new questions about the authority machines should exercise. Meanwhile, expanding connectivity makes the consequences of misplaced trust harder to contain.

These developments point toward a common requirement: organizations must retain control over relationships that cannot remain static.

We should understand why a particular system is trusted and what that trust permits. Just as importantly, we need the ability to reconsider that decision when circumstances change.

The real test of a trusted system is not simply whether it can establish a secure connection. It is whether the organization can continue to govern that relationship as the environment evolves.

Trust should enable a system to perform its purpose. It should never become permanent permission to do everything else.

Next: When Machines Make Decisions, Who Is Accountable? As AI agents and autonomous systems take on more responsibility, where should organizations draw the line between automated authority and human accountability?