Zero Trust Foundations: Running AAVI Through the Device Pillar

Why the question "is this a device I trust?" now has to include laptops, phones, servers, containers, microservices, and the AI agent that never sleeps and never orders decaf.

Summary: This week we bring the Device pillar into our transaction flows and Zero Trust policy statements. Device trust used to mean "is this laptop managed and patched?" It now has to answer the same question for phones, servers, containers, service accounts running workloads, microservices calling each other all day long, and AI agents that can act on their own. We will run Device through AAVI, then check what happens when the "device" in question doesn't have a keyboard, a screen, or the good sense to know it's been compromised.

Grab a fresh cup of coffee, and maybe pour a second one for whatever is about to try to log in on your behalf. Last time, we ran AAVI through the Identity pillar and closed with a promise: bring Device into the same transaction flows and ask whether the request should be trusted from the device or workload being used right now. Identity told us who is asking. Device is about to tell us what that "who" is asking from, and increasingly, the "who" is not a person at all.

Before we get into the model, let's talk about why this matters this week instead of some hypothetical future week. In March 2026, an Iran-linked group wiped over 200,000 medical devices at Stryker by exploiting a single compromised Microsoft Intune account: one device management credential, one very bad day, across an entire fleet of endpoints that trusted whatever that management platform told them to do. Meanwhile, the Shai-Hulud worm spent 2025 self-propagating through npm and GitHub, quietly turning developer workstations and CI/CD pipelines into unwilling accomplices. And OpenAI disclosed an incident where an AI agent used stolen credentials and tried to access another AI company's systems entirely on its own initiative. None of those started with a person typing a bad password. They started with something the environment assumed was a trustworthy device or workload. That is exactly the gap the Device pillar exists to close.

Device Trust Is Not Just "Is It Registered?"

For a long time, device trust meant asking one question: is this a company owned, domain joined machine? If yes, carry on. That question made sense when most devices were laptops and desktops sitting on a corporate network. It does not hold up well against the modern protect surface, where "device" has quietly expanded to include personal phones checking email, a vendor's laptop connecting for support, a container spinning up for ninety seconds to process a job, a microservice calling another microservice a few thousand times a minute, and an AI agent making tool calls against production data at 2:00 a.m. because someone asked it to "clean up the backlog."

Device, in Zero Trust terms, is not a single object. It is any endpoint, workload, or computing context that a request travels through or originates from. That includes laptops and phones, servers and virtual machines, containers and pods, IoT and medical devices, service accounts running scheduled jobs, microservices, automation scripts, and yes, AI agents and their underlying compute. Each one has a posture. Each one can be healthy or compromised. Each one participates in the trust decision whether we designed it to or not.

Our Model Protect Surface, Continued

We are still working with the same messy hybrid business application: on premises core, legacy database, corporate identity platform, SaaS analytics export, cloud file storage, internal admin tools, and occasional vendor access. Now let's ask the Device question about our earlier transactions. When the finance user exports a report, what device is that request coming from: a managed corporate laptop, a personal phone with a browser tab open, or something in between? When the service account moves data to SaaS analytics, what host or workload identity is actually executing that job, and is it the one we expect? When the vendor connects for support, are they on a device we have ever seen before, or a random laptop that happened to have the right credentials?

Notice that Device does not replace Identity. It adds a second signal to the same decision. A known user on an unmanaged, unpatched device attempting a sensitive export deserves a different answer than the same user on a managed, healthy device. That is the whole point: no pillar wins alone, and Device is where "who" meets "from what."

AAVI Through the Device Pillar

Assess: What Is Actually Talking to This Protect Surface?

In Assess, we inventory every endpoint and workload that touches the protect surface, human operated or not. That means corporate laptops and desktops, personal and BYOD phones, vendor and contractor machines, servers and virtual machines hosting the application, containers and orchestration nodes, network appliances, IoT or medical devices if any are in scope, service accounts and the hosts or clusters they run on, CI/CD runners, and any AI agents, assistants, or autonomous workflows that can call into the application or its data.

For our protect surface, assessment might show that most workforce laptops are managed and enrolled in an MDM platform, most employees connect from company issued phones, but a few users still access reports from personal devices because "it was faster." The vendor connects from a machine we have never inventoried. The service account that moves data to SaaS analytics runs on a server nobody has re imaged in three years. And somewhere in the mix, someone quietly connected an AI assistant to the reporting tool so it could "summarize exports on request," and nobody wrote that down anywhere.

That last one is not a hypothetical. It is exactly the kind of gap that shows up in nearly every real assessment, and it is exactly the kind of gap that made headlines this year.

Adapt: Turn Device Posture Into a Real Input

Adapt is where we make device posture actually count in the decision, instead of being a checkbox that gets ignored the moment someone is in a hurry. For managed corporate devices, that may mean requiring device health checks, disk encryption, current patch levels, and endpoint protection status before allowing access to sensitive functions like export. For personal or BYOD devices, it may mean limiting them to lower risk actions, requiring additional verification, or routing them through an isolated access path instead of full network access.

For workloads, containers, and service accounts, Adapt looks a little different but asks the same question: can we prove this compute environment is what we expect it to be? That might mean moving service accounts onto scoped, short lived workload identities instead of static credentials baked into a config file, requiring signed and attested container images before deployment, and making sure automation jobs run from known, monitored hosts rather than "whatever server had room."

For AI agents specifically, Adapt means treating the agent's execution environment as a device in its own right. Where does the agent run? What can it reach from there? Is its runtime isolated, monitored, and limited to the tools and data it actually needs, or does it have the same network reach as everything else in the data center because setting that up "took too long"?

Verify: Prove the Device Actually Influenced the Outcome

Verify asks the uncomfortable question: did device posture actually change anything, or did we just log it and move on? For our protect surface, verification should show that unmanaged or unhealthy devices were actually blocked or limited from sensitive actions, that vendor connections came from an approved and recognized machine, that the service account's workload identity matched its expected host and behavior pattern, and that the AI agent's actions can be traced back to the runtime and scope it was supposed to be operating within.

If we cannot prove the device was evaluated, we CANNOT count device trust as part of the architecture yet.

That is not a lesser version of the identity rule from a couple of posts back. It is the same rule, applied to a different pillar. A policy that says "require a managed device for export" is worth nothing if nobody can produce evidence that device posture was actually checked at the moment of the export, not just at the moment of login.

Iterate: Keep Closing the Side Doors

Iteration for Device usually starts by cutting off the easiest side doors first. The first pass might close the BYOD export path and require managed devices for sensitive actions. The next might retire the untracked vendor laptop in favor of a provisioned, monitored access method. The next might replace the static service account credential with a rotated workload identity. The next might bring that quietly connected AI assistant into the inventory with a defined scope, an owner, and a kill switch. Each pass reduces the number of devices and workloads that are trusted simply because nobody got around to checking them.

Non Human Devices: Microservices, Workloads, and AI Agents Show Up Too

Here is the part of the Device pillar that trips people up: when we say "device," muscle memory pictures a laptop. But in a modern hybrid environment, the devices making the most requests per hour are frequently not carried by anyone. Microservices call each other constantly, containers spin up and disappear in minutes, scheduled jobs run from ephemeral compute, and AI agents execute multi step tasks across systems without a human clicking anything in the moment.

Each of these is a device in the Zero Trust sense: it has an execution context, it can be healthy or compromised, and it makes requests that need to be evaluated the same way we evaluate a laptop's health before letting it touch sensitive data. A microservice running on a compromised node is no different, from a trust standpoint, than an employee's laptop running a keylogger. The request looks legitimate right up until someone checks where it is actually coming from.

The practical questions are the same ones we ask about a laptop, just aimed at a different kind of endpoint. What is this workload's identity, and can it be verified independently of the request itself? What node, cluster, or runtime is it executing on, and is that runtime patched, attested, and monitored? What is its normal blast radius (which services, data, and actions should it ever touch), and would we notice if it suddenly reached further than that? For AI agents in particular, add one more: what happens if this agent's credentials or runtime are compromised, and can we shut it down without shutting down the business process it supports?

This is exactly the gap that Stryker's Intune compromise and the Shai-Hulud worm exploited, not weak passwords, but device and workload trust that nobody was actively verifying at the moment it mattered. And it is exactly the gap that let an AI agent attempt unauthorized access on its own initiative: the agent's execution environment was treated as background infrastructure instead of a device that needed its own posture check.

Cross Functions Keep Device Honest

Visibility and Analytics need to show more than "device connected." They need to show device health, patch state, managed status, workload identity, container image provenance, and, for AI agents, which tools and data sources were touched during a session. If all we can produce is "a device connected successfully," that is a receipt with no order details, same as we said about identity two posts back.

Automation and Orchestration should enforce device posture consistently, without depending on someone remembering to check. Unhealthy devices should be blocked or limited automatically. Workload identities should rotate on a schedule, not when someone remembers. Container images should be scanned and attested before deployment, not after an incident.

Governance should own the exceptions. If a personal device is temporarily allowed for a business reason, that exception needs an owner and an expiration date. If an AI agent needs broader access for a project, that grant needs a review cadence and a sunset clause, otherwise it becomes the quiet vendor account of the AI era, still connected two years after the project ended.

Before the Next Cup

Here is your homework before the next cup of coffee: pick one transaction from your protect surface and list every device, workload, or execution context involved in it, not just the human's laptop, but the servers, containers, service accounts, and any AI agents that participate. For each one, ask: can we prove its current posture, and would we notice if that posture changed for the worse?

Call to action: This week, do four small things. First, inventory the non human devices (microservices, workloads, containers, service accounts, and AI agents) touching one real transaction, and note which ones nobody has looked at in the last year. Second, check whether device posture is actually enforced for a sensitive action, not just logged. Third, find one AI agent, automation script, or service account with broader reach than its job requires, and give it an owner and a boundary. Fourth, ask whether your visibility can reconstruct "which device, in what condition, did this," not just "someone logged in."

Remember, this series is the lighter, consolidated version of the process I walk through in full in ZT Foundations: Building Zero Trust with the Tools You Already Have, with the companion volume ZT Foundations: Protect Surface Walkthroughs available for readers who want to see the methodology applied to realistic scenarios. Both are available through cletustaylor.com and major distributors. If this series is useful to your team, I would be grateful if you picked up a copy or shared it along.

On a personal note, I am still looking for ARC reviewers for my Finding Truths book, A Student of Truth. You can sign up at cletustaylor.com.

Next time, we bring the Network pillar into these same transaction flows and ask the next question: even if we trust the identity and the device, how far should this request actually be allowed to travel? As always, send your thoughts, questions, and real world device trust horror stories to hello@cletustaylor.com, or leave a comment wherever you're reading this. I'll have the coffee ready, and I promise not to make you patch every container before the first sip, unless it's the one running the AI agent.

#ZeroTrust #Cybersecurity #DeviceTrust #EndpointSecurity #AIsecurity #NonHumanIdentity #SecurityArchitecture #ZeroTrustArchitecture #MicroservicesSecurity #CyberSecurityAwareness