Zero Trust Foundations: Running AAVI Through the Application and Workloads Pillar

Why "the user is allowed to use this application" is a different question than "the application is allowed to do this specific thing right now," and why that gap matters even more once workloads and AI agents are the ones calling the shots.

Summary: This week we bring the Application and Workloads pillar into our transaction flows and Zero Trust policy statements. Identity told us who is asking. Device told us what they are asking from. Network told us how far that request should be allowed to travel. Application asks the next question: once a request arrives at the application, does the application behave the way we actually expect for this specific action, or does it just do whatever it was coded to do because nobody ever told it otherwise. That question gets sharper once we account for microservices, APIs, automation, and AI agents that can call functions and trigger workflows on their own.

Grab a fresh cup of coffee. Last time, we ran AAVI through the Network pillar and closed with a promise: bring Application into the same transaction flows and ask whether the application itself behaves the way we expect, even after identity, device, and network have already said yes. This week we keep that promise, and it turns out this pillar has some of the most interesting failure modes in the entire series, mostly because applications and workloads have quietly gotten a lot more capable than the access models built around them.

Here is why this matters right now, not someday. Security researchers disclosed CVE-2025-32711, nicknamed EchoLeak, showing that a single crafted document sent to an AI assistant could trigger it to retrieve and leak sensitive internal data, with no user clicking anything and no obvious warning sign. Around the same time, researchers documented cases of AI coding agents being tricked through manipulated prompts into leaking private repository contents through a workflow that was never designed to be an exfiltration path, and at least one widely discussed incident where an autonomous coding agent deleted a production database while operating with far more authority than the task required. None of those were identity failures. None of them were device failures. They were application and workload failures: the application did exactly what it was capable of doing, because nobody had defined what it should be allowed to do for that specific action.

Application Trust Is Not "Is It On the Approved List"

For a long time, application security meant asking whether an application was approved, patched, and running on supported infrastructure. Those questions still matter, but they answer a different question than the one Zero Trust cares about most. The Zero Trust question is not "is this application allowed to exist." It is "is this application, or this specific function within it, allowed to perform this specific action, on this specific data, right now."

That distinction matters because most applications, and nearly every workload and AI agent built on top of them, are granted access at a much broader level than any single transaction requires. A reporting application that can query the database is usually granted broad database access, not scoped access limited to exactly the queries the reporting function needs. An AI assistant connected to a business system is usually granted whatever the connector supports, not the narrow set of actions the actual use case requires. Application trust has to move from "is this a recognized application" to "is this specific action, by this specific application or workload, appropriate right now."

Our Model Protect Surface, Continued

Back to our familiar messy hybrid application: on premises core, legacy database, corporate identity platform, SaaS analytics export, cloud file storage, internal admin tools, and vendor support access. Now we ask the Application question about the same transactions. When the finance user exports a report, is the export function itself scoped to only the fields and records that user is allowed to see, or does the application quietly hand back everything and rely on the user to behave. When the service account moves data to SaaS analytics, does that workload have permission to read only the specific tables it needs, or does it have the same broad database access an administrator would have, just because that was easier to configure. When an administrator uses an internal tool to change configuration, does that tool enforce which specific settings that administrator can touch, or does "administrator" mean "can do anything the tool is technically capable of."

This is where Application and Workloads becomes the pillar that catches what the earlier three cannot. A known identity, on a healthy device, taking an expected network path, can still cause serious damage if the application itself has no concept of least privilege at the function level. The request looked completely legitimate right up until the application did something nobody meant to authorize.

AAVI Through the Application and Workloads Pillar

Assess: What Can This Application or Workload Actually Do

Assess for this pillar means inventorying not just which applications exist, but what each one, and each workload, service, API, and AI agent connected to it, is actually capable of doing. That includes the application's own permissions against the database and other systems, the specific functions and API endpoints it exposes, which of those functions perform sensitive actions like export, deletion, or configuration change, and which service accounts, microservices, automation scripts, or AI agents call into it and with what scope.

For our protect surface, assessment likely shows an application with broader database permissions than any single function requires, an export feature with no field level restriction, a service account with more table access than the SaaS integration actually uses, and possibly an AI assistant or automation tool connected somewhere in the workflow with access nobody has fully documented. That last one deserves particular attention, since AI agents and assistants are exactly the kind of workload that tends to get connected quickly, for a good reason, and then never gets its scope reviewed again.

Adapt: Move From Application Level to Function Level Authorization

Adapt is where we narrow application and workload permissions down to what each specific function actually needs, rather than what the application was broadly granted. That might mean scoping the export function to only the fields and records the requesting user's role allows, limiting the service account's database access to the exact tables the SaaS integration reads, and defining explicit boundaries for any AI agent or automation tool, including which actions it can take, which data sources it can read, and which functions are entirely off limits regardless of what it is asked to do.

This is also where prompt and action boundaries matter for AI specifically. An AI agent connected to a business application should have the same discipline applied to it that we apply to a human user with a scoped role: it should only be able to call the functions relevant to its purpose, it should not be able to chain those functions together in ways nobody intended, and there should be a defined limit on what a single request, however it arrives, can actually cause the application to do.

Verify: Prove the Application Only Did What It Was Supposed To

Verify asks whether the application or workload actually stayed within its intended behavior, not just whether access was technically available. Can we prove that the export function only returned the fields and records the user's role allowed. Can we prove the service account's activity matched its expected pattern and never touched a table outside its scope. Can we prove that an AI agent's actions during a session matched its approved function list, and that nothing it did fell outside the boundaries it was given.

If we cannot prove the application or workload stayed within its intended behavior, we CANNOT count application level trust as part of the architecture yet.

This is the same discipline we have applied to every pillar so far, aimed at a different layer. A scoped function is not evidence of anything if nobody can show that the scope actually held during a real transaction.

Iterate: Keep Narrowing What Each Function Can Do

Iteration for this pillar usually looks like steadily shrinking the gap between what an application or workload is technically capable of and what it is actually supposed to do. The first pass might scope the export function. The next might tighten the service account's database permissions. The next might formally define the AI agent's approved function list and start logging every call it makes against that list. The next might apply the same discipline to the next application in the portfolio. Each pass reduces how much damage a single misused function, compromised workload, or manipulated AI agent could actually cause.

Workloads and AI Agents Are Application Actors Too

It is worth saying plainly: a microservice, an automation script, and an AI agent are all application actors in the Zero Trust sense, not background infrastructure. Each one calls functions, each one can be granted more authority than its task requires, and each one can be manipulated or compromised in ways that look, from the application's point of view, like a normal request.

The practical questions are consistent across all of them. What functions can this workload or agent call. Is that list the minimum required for its actual purpose, or the maximum the platform happened to allow. What happens if it is tricked, through a manipulated input, a crafted document, or a chained set of instructions, into calling a function it was technically permitted to use but never should have used in that context. And critically, is there a hard boundary somewhere, a function it simply cannot call no matter how it is asked, so that a manipulated agent or compromised workload has a ceiling on the damage it can do.

That last point is exactly what was missing in the incidents mentioned earlier. An AI assistant that could retrieve and summarize internal documents did so through a crafted input it was never meant to trust. A coding agent that could modify repository workflows did so because nothing stopped it from treating a manipulated prompt as a legitimate instruction. An autonomous agent that could run database commands ran a destructive one because nothing in its function scope drew a line between routine maintenance and irreversible action. In each case, the application or workload did something it was technically capable of doing. The gap was never closing that gap in advance.

Cross Functions Keep Application and Workloads Honest

Visibility and Analytics need to show which functions were called, by which application or workload, with what parameters, and against what data, not just that "the application processed a request." For AI agents specifically, that means logging which tools were invoked, what inputs triggered them, and what the agent actually did as a result.

Automation and Orchestration should enforce function level scope consistently, rather than depending on every developer or integration remembering to apply least privilege by hand. Scope reviews, permission changes, and AI agent function approvals should follow a repeatable process, not a one time setup that nobody revisits.

Governance should own the review cadence for what each application, workload, and AI agent is allowed to do, and should require a documented business justification any time that scope grows. An AI agent's access should never be treated as permanent just because removing it might be inconvenient.

Before the Next Cup

Here is your homework before the next cup of coffee: pick one application or workload in your protect surface and list every function or action it can actually perform, not just the ones it is normally used for. Then ask which of those functions are broader than the business need requires, and which ones, if misused or manipulated, could cause damage nobody has planned for.

Call to action: This week, do four small things. First, find one function in a real application, an export, a deletion, a configuration change, and confirm whether it is scoped to the minimum data and permissions the task requires. Second, check one service account or workload's database or system permissions against what it actually uses, not what it was originally granted. Third, if an AI agent, assistant, or automation tool is connected anywhere in your protect surface, write down its approved function list, and identify at least one action it is currently capable of that it should never be allowed to take. Fourth, ask whether your visibility can show exactly which functions were called during a real transaction, not just that the application was used.

Remember, this series is the lighter, consolidated version of the process I walk through in full in Zero Trust Foundations Volume I: Building Zero Trust with the Tools You Already Have. The book is available now through cletustaylor.com while I work through relaunching it across additional distribution channels, so if you would rather order it directly, that is the place to do it right now. There is also Protect Surface Walkthrough, the companion volume to Volume I, which walks through example protect surface evaluations and realistic outcomes for readers who learn best by seeing the process applied to real scenarios. Both books are meant to go deeper than this blog series can, and if your team is trying to make Zero Trust practical instead of theoretical, I would be grateful if you picked up a copy, shared it with your team, or pointed someone toward the series.

On a personal note, I am still looking for ARC reviewers for my Finding Truths book, A Student of Truth. If you would like to sign up to be a reviewer, you can do that at cletustaylor.com.

Next time, we bring the Data pillar into these same transaction flows and ask the final pillar question: even when identity, device, network, and application all check out, does the data itself carry enough context to influence the decision, and does it matter what happens to that data once it leaves. As always, I would love to hear your thoughts, questions, pushback, and real world examples. Where has an application or workload had more authority than its actual job required in your environment. Have you connected an AI agent or automation tool somewhere and never gone back to check its scope. Send your comments and ideas to hello@cletustaylor.com, or leave a comment wherever you are reading this. I'll have the coffee ready, and I promise not to make you diagram every API endpoint before the first sip, unless one of them can delete a production database.

#ZeroTrust #Cybersecurity #ApplicationSecurity #WorkloadSecurity #APIsecurity #AIsecurity #LeastPrivilege #SecurityArchitecture #ZeroTrustArchitecture #CyberSecurityAwareness