Your engineers need elevated access to fix a critical incident. Your zero trust policy says every request must be verified. Right now, one of those things slows the other down. It doesn’t have to.

Zero trust is one of those security principles that is almost universally accepted in theory and almost universally painful in practice. The concept is sound: never trust, always verify. Every access request – regardless of who is making it, where they are or what they have accessed before – should be evaluated against policy before it is granted. No implicit trust. No standing privileges. No exceptions.

The problem is not the principle. The problem is what happens when a senior engineer needs emergency access to a production firewall at 3am to stop a service outage, and the access request is sitting in a queue waiting for someone to approve it.

This is the fourth post in our series exploring how agentic AI, grounded in trusted cyber asset intelligence, can deliver immediate value in IT service management and operations. In our first post we made the case that AI agents are only as good as their data. In our second post we built a change manager agent. In our third post we tackled anomaly correlation. Now we address something that sits at the intersection of security and operational efficiency: a zero trust access controller agent that can enforce policy in real time, without becoming the bottleneck that undermines the very operations it is meant to protect.

The Access Approval Bottleneck

In most organisations, the process for requesting elevated access to infrastructure, applications or devices follows a familiar pattern. An engineer or operator determines they need access – perhaps to implement an approved change, perhaps to investigate or resolve a live incident, perhaps to perform routine maintenance on a system they do not ordinarily administer. They raise a request. That request goes into a queue. Someone – an application owner, a security team member, a manager – reviews and approves or declines it.

In principle, this is good governance. In practice, it creates problems that range from the frustrating to the actively harmful:

• Delay in incident resolution. When a critical incident is under way and the responder needs break-glass access to a system, every minute spent waiting for approval is a minute of continued service degradation. Mean time to resolve goes up. Business impact goes up. Customer trust goes down.
• Change implementation bottlenecks. Scheduled changes have implementation windows. If access approvals are not processed in time, the change either proceeds late – compressing the available time for testing and back-out – or is deferred entirely to the next window, delaying the work by days or weeks.
• Inconsistent enforcement. Under pressure, approvers may rubber-stamp requests without proper scrutiny. In quieter moments, they may apply stricter standards. The result is a zero trust policy that is enforced unevenly – which is to say, not really enforced at all.
• Approval fatigue. Like the alert fatigue we discussed in our previous post on anomaly correlation, the sheer volume of access requests can overwhelm the humans responsible for reviewing them. When everything requires manual approval, the quality of every individual approval decision declines.

The irony is acute: a policy designed to improve security can, when implemented purely through manual processes, actively degrade both security and operational performance.

What the Zero Trust Access Controller Agent Does

The zero trust access controller agent applies the organization’s zero trust policy to every elevated access request – automatically, consistently and at the speed the situation demands. It does not replace the policy. It enforces it more reliably than any manual process could.

Here is how it works, step by step.

1. Receive and Parse the Request

The agent receives the access request and extracts the key parameters: who is requesting access, what they are requesting access to (infrastructure, device, application service or software), what level of access they need, and why. The justification might be a planned change request, a live incident requiring break-glass access, or a routine operational task.

2. Evaluate the Requester

Zero trust begins with the individual. The agent assesses the requester’s role, their normal access entitlements, their history of previous access requests and their relationship to the asset or service in question. An engineer who regularly works on the system they are requesting access to presents a different profile to someone who has never accessed it before.

3. Assess the Target Asset or Service

This is where cyber asset intelligence becomes critical. The agent examines the asset, device, infrastructure component or application service that the request relates to:

• What is it, and how critical is it? A development server and a production database are not equivalent. The agent understands the classification, the business criticality and the service dependencies of the target.
• What is its current risk posture? Are there known vulnerabilities on this asset? Is it running unsupported software or firmware? Has it been flagged for any security concerns? Is it currently subject to any active threats or incidents?
• What is its lifecycle status? Is the infrastructure under warranty and vendor support, or has it reached end of life? Granting elevated access to unsupported infrastructure carries inherently greater risk.
• What are its relationships and dependencies? If the agent grants access to this asset, what else could the requester potentially reach? What are the blast radius implications if something goes wrong?

4. Consider the Operational Context

The agent does not evaluate the request in a vacuum. It considers the broader operational picture:

• Is this linked to an approved change? If the access request references a change record, the agent checks that the change is genuine, approved and currently within its implementation window. It may also examine what the change is actually doing – if the purpose is to patch or upgrade the infrastructure to remove known vulnerabilities, the presence of those vulnerabilities is not a reason to deny access but rather a confirmation that access is needed.
• Is this linked to a live incident? If break-glass access is being requested to resolve an active incident, the agent verifies the incident exists, assesses its severity and understands the urgency. A priority-one incident affecting a revenue-generating service demands a different response time to a low-severity issue that could wait until morning.
• Does this conform to the zero trust policy? The agent evaluates the request against the organisation’s defined zero trust rules – permitted access levels, required justifications, time-bound access constraints, multi-factor authentication requirements and any conditional provisions.

5. Deliver a Decision

Having assessed the requester, the target, the operational context and the policy, the agent issues one of three outcomes:

• Approve: the request is within policy, the risk is acceptable, the justification is valid and no additional risk factors have been identified. The agent goes further than simply approving: It issues the action to grant access, enabling the requester to proceed immediately. Access is time-bound and logged.
• Conditionally approve: the request is broadly acceptable but carries elements of elevated risk. Perhaps the target asset has known vulnerabilities unrelated to the current change, or the requester does not normally work on this system. The agent grants access but flags the conditions – and may impose additional constraints such as reduced access duration, enhanced logging or a requirement for a second approver to confirm within a defined window.
• Deny: the request falls outside policy, the risk is unacceptable, or the justification is insufficient. The agent provides clear, specific feedback explaining why the request was denied – not a generic rejection, but a reasoned explanation that tells the requester exactly what is missing or what risk was identified. The request is then escalated to the human owner of the relevant application service or infrastructure for a final decision.

Speed Where It Matters Most

The impact is most dramatic in incident management – precisely where access delays are most costly. Consider a scenario: a critical application service is down, the on-call engineer has been paged, they have identified the likely cause and they need elevated access to a production server to implement the fix.

Under the current model, they raise an access request. They wait. Perhaps the approver is asleep. Perhaps the approver is dealing with another issue. Perhaps the approver is available but needs to check the asset details, review the engineer’s access history and verify the incident before feeling comfortable granting break-glass access. Minutes pass. The outage continues. Customers are affected. Revenue is lost.

With the zero trust access controller agent, the engineer raises the request and receives a decision in seconds. The agent has already verified the incident, assessed the asset, checked the engineer’s credentials and history, evaluated the risk against policy and determined that access should be granted. The engineer is working on the fix within a minute of requesting access. The policy has been enforced. The audit trail is complete. And the outage duration has been reduced from the time it takes a human to wake up and process an approval to the time it takes an AI agent to reason through a decision.

That is not a marginal improvement. In incident management, it is transformative.

The Data the Agent Needs

By now, the recurring theme of this series should be familiar. The zero trust access controller agent cannot function without comprehensive, trusted, continuously updated knowledge of the technology estate:

• Asset inventory: every device, server, network component, application and service, with accurate classification and criticality ratings.
• Vulnerability intelligence: known vulnerabilities on each asset, their severity and whether they are being actively exploited.
• Lifecycle and support status: warranty information, end-of-life dates, vendor support status.
• Relationship mapping: how assets connect to each other, what services they support, what the dependencies and blast radius implications are.
• Configuration and compliance data: whether assets meet baseline security configurations and organizational standards.

This is the asset intelligence that platforms like Lansweeper provide – deep, automated discovery across IT, OT, IoT and cloud environments, continuously updated and contextualized. Without it, the agent is enforcing zero trust policy against an incomplete picture of reality. With it, every access decision is grounded in the actual state of the estate at the moment the decision is made.

As with the agents we have discussed in previous posts, this intelligence can be delivered through synchronization into the ITSM platform, direct API calls from the agent, or through MCP server integration as the Model Context Protocol ecosystem matures.

Zero Trust That Works With Operations, Not Against Them

The zero trust access controller agent resolves a tension that has plagued security and operations teams for years. Security wants every access request verified against policy. Operations wants access granted quickly enough to do the job. These goals are not inherently contradictory. They only conflict when the verification process is manual, slow and inconsistent.

An AI agent that can verify, assess, decide and act in seconds delivers both outcomes simultaneously: rigorous policy enforcement and operational speed. The policy is applied consistently to every request, regardless of time of day, workload or the approver’s mood. And when human judgement is genuinely needed – when the agent conditionally approves or denies a request – the human reviewer receives a complete risk assessment and a clear explanation, enabling a faster and better-informed final decision.

This is not about removing humans from security decisions. It is about ensuring that when humans make those decisions, they are making the ones that actually require human judgement – and making them with the full picture in front of them.

This Series So Far – And What Comes Next

This is the fourth post in our series on agentic AI in ITSM and IT operations. We have now explored:

• Blog 1: Why your AI agents are only as good as the data behind them – the foundational argument for trusted cyber asset intelligence.
• Blog 2: The change manager agent – transforming change enablement by automating risk assessment and approval recommendations.
• Blog 3: The anomaly correlation agent – turning asset change events into intelligent, classified, actionable recommendations.
• Blog 4: The zero trust access controller – enforcing security policy at the speed operations demand.

Across every use case, the same principle holds: the agent is only as good as the data behind it. Trusted, comprehensive, continuously updated cyber asset intelligence is not optional in the era of agentic AI. It is the foundation upon which everything else is built.