{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig3ejqgn5bxw5yx53yc4xtypw2rpklpfajil5ffe2n3trogcntbee",
    "uri": "at://did:plc:sgnbp3iisuckzdcnqv6ygsnp/app.bsky.feed.post/3mgdagkmy3ub2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreihmrpiwn3epljtksgad4n4pm3s25o3ly6jk6lg6uw6z7p73ltgbii"
    },
    "mimeType": "image/jpeg",
    "size": 272198
  },
  "description": "AI didn't just create new attack surfaces. It fundamentally changed who—and what—is requesting access in your environment. Zero Trust needs an upgrade for a world where autonomous agents outnumber human users.",
  "path": "/zero-trust-in-the-age-of-ai-why-the-classic-model-isnt-enough-anymore/",
  "publishedAt": "2026-03-05T16:40:39.000Z",
  "site": "https://guptadeepak.com",
  "tags": [
    "Zero Trust",
    "architecturally more complex",
    "_Deepak Gupta_"
  ],
  "textContent": "Here's a statement that should make any security architect pause:\n\n**_In most enterprise environments today, machine identities - service accounts, API keys, deployment pipelines, and increasingly AI agents - outnumber human identities by a significant margin. In AI-native companies, that ratio is already 10 to 1 or higher._**\n\nZero Trust was designed with human users as the primary subject. The model assumes identity belongs to a person who authenticated with credentials, uses a device you can evaluate, and accesses applications in recognizable patterns. When something deviates from that pattern, behavioral analytics flags it.\n\nAI agents don't fit that model. And the mismatch is creating security gaps that traditional Zero Trust frameworks weren't designed to close.\n\n* * *\n\n## What Changed When AI Entered the Picture\n\nThe first wave of AI in enterprise environments was relatively contained. Machine learning models trained on internal data, analytics pipelines, recommendation engines. These were workloads - they had identities, made API calls, and could be secured reasonably well with existing approaches.\n\nThe second wave - large language models, AI agents, and autonomous systems - is different in kind, not just in degree.\n\n**AI agents act autonomously.** A human user making access requests follows recognizable patterns. An AI agent running a workflow might make hundreds or thousands of API calls in minutes, query multiple data sources in sequence, generate and execute code, and trigger downstream actions - all autonomously. The behavioral baseline for an AI agent looks nothing like a human user.\n\n**AI agents operate across long contexts.** An AI workflow might start with a user request, retrieve context from multiple systems, call external APIs, process results, and write output to another system - all in a single execution. This multi-hop, multi-system access pattern is exactly what lateral movement looks like. Distinguishing legitimate agent behavior from adversarial behavior is genuinely hard.\n\n**AI agents inherit and amplify permissions.** If an AI agent runs in the security context of a human user or a service account with broad permissions, it can do whatever that identity can do. And because it acts autonomously and at machine speed, any permission misuse happens before a human can intervene.\n\n**AI agents can be manipulated.** Prompt injection attacks - where malicious content embedded in data the agent processes causes it to perform unintended actions - are a real and growing class of attack. An agent that trusts content from external sources without verification can be weaponized by that content.\n\n* * *\n\n## The Machine Identity Problem\n\nBefore even getting to AI agents, there's a foundational problem: most organizations have poor visibility and governance over non-human identities.\n\nWhen I was scaling a CIAM platform to handle billions of user authentications, we were acutely aware of human identity management. But the service accounts, API keys, and machine-to-machine connections multiplied faster than anyone tracked them. This pattern holds across the industry.\n\nA 2024 assessment across enterprise environments found that organizations with good visibility into their human identity inventory often had three to five times more non-human identities than human ones - and a fraction of the governance.\n\nHere's what that looks like in practice:\n\n  * API keys embedded in code repositories with no expiration and no ownership\n  * Service accounts with broad permissions granted for a project that ended two years ago\n  * OAuth application grants that were authorized by employees who have since left\n  * AI pipeline credentials with read access to data systems far beyond what the pipeline actually needs\n\n\n\nEvery one of these is a potential pivot point for an attacker. And because machine identities are less visible and less monitored than human ones, they're increasingly the preferred target.\n\nThe SolarWinds breach in 2020 exploited precisely this gap. The malicious code inserted into the build pipeline operated using legitimate service account credentials. No human user behaved anomalously. The compromise lived entirely in the machine-to-machine communication layer.\n\n* * *\n\n## How Zero Trust Needs to Evolve for AI\n\nClassical Zero Trust principles still apply. Never trust, always verify. Least privilege. Assume breach. But the implementation needs to extend in several specific directions to handle AI agents and machine identities effectively.\n\n### 1. Every AI Agent Needs Its Own Identity\n\nAn AI agent should not run under a shared service account or a human user's identity. It should have its own workload identity, with permissions explicitly scoped to what that specific agent needs to do its specific job.\n\nThis means:\n\n  * Workload identity credentials issued per-agent, not per-application\n  * Short-lived credentials where possible (tokens with brief expiry rotated frequently)\n  * No standing permissions - access granted when needed, revoked when the workflow completes\n  * Machine identity lifecycle management as rigorous as human identity management\n\n\n\nThe practical challenge: AI frameworks and orchestration platforms vary widely in how they handle identity. Some make this easy; many require deliberate work to implement correctly. Treat agent identity as a first-class design requirement, not an afterthought.\n\n### 2. Least Privilege for Agentic Workflows Is Harder - and More Important\n\nA human user with least privilege access typically needs read access to their own work, write access to their own projects, and limited access elsewhere. Scoping that is well understood.\n\nAn AI agent that orchestrates a complex workflow might legitimately need to read from a database, call an external API, write to a document store, and trigger a notification - in sequence, not simultaneously. Traditional least privilege models often grant all the permissions the workflow might ever need upfront.\n\nA more sophisticated approach uses just-in-time permission grants: the agent requests and receives the permission it needs for each step, uses it, and releases it. This requires the orchestration layer to mediate permission requests rather than granting all permissions at initialization.\n\nThis is architecturally more complex but significantly reduces the blast radius if the agent is compromised or manipulated mid-workflow.\n\n### 3. Protect AI Agent Inputs and Outputs\n\nPrompt injection is the Zero Trust problem for the AI data plane. If an AI agent processes data from external sources - web content, emails, documents, user inputs - any of that content could contain instructions intended to manipulate the agent's behavior.\n\nZero Trust for AI inputs means:\n\n  * Treating all external content as untrusted data, not as instructions\n  * Implementing input sanitization and validation before agent processing\n  * Separating the trust level of agent instructions (from your system prompt, your code) from the trust level of agent inputs (user data, external content)\n  * Monitoring agent outputs for anomalies that might indicate manipulation\n\n\n\nThis is a relatively new problem domain, and the tooling is still maturing. But the principle maps directly to existing Zero Trust thinking: explicit verification, never implicit trust.\n\n### 4. Behavioral Baselines for AI Agents\n\nUEBA (User and Entity Behavior Analytics) was built for human users and, to some extent, traditional service accounts. AI agents behave differently and require different baselines.\n\nAn AI agent running normally might make 500 API calls in ten minutes. That would be catastrophically anomalous for a human user. Building baselines that correctly distinguish normal high-volume agent behavior from anomalous agent behavior - excessive data access, calls to unexpected endpoints, anomalous output volumes - requires agent-aware analytics.\n\nThis means:\n\n  * Agent activity should be logged separately from human user activity, with agent-specific context\n  * Behavioral baselines should be established per-agent-type, not applied from human user templates\n  * Anomaly detection rules should account for the burst-and-pause pattern typical of AI workflows\n  * Threshold violations should trigger agent suspension and review, not just alerting\n\n\n\n### 5. Human-in-the-Loop for High-Stakes Decisions\n\nThe most dangerous class of AI agent action is the irreversible high-stakes operation: sending an external communication, modifying production data, executing a financial transaction, deprovisioning an account.\n\nZero Trust for AI agents should include explicit checkpoints for these operations, where a human must review and approve before the agent proceeds. This isn't a performance optimization - it's a security control that limits the damage an adversarial manipulation can cause.\n\nDesigning these checkpoints into the workflow architecture from the beginning is far easier than retrofitting them later.\n\n* * *\n\n## The Threat Landscape AI Is Creating\n\nUnderstanding what you're defending against sharpens how you build defenses.\n\n**AI-assisted reconnaissance:** Attackers are using AI to accelerate target profiling, identify exposed credentials and API keys in public repositories, and analyze large datasets for attack paths. The speed of attack preparation has increased dramatically.\n\n**AI-generated phishing:** The barrier to convincing social engineering has dropped. AI-generated phishing content can be personalized, grammatically correct, and contextually appropriate at scale. Traditional spam filters that look for poor writing or generic templates are less effective.\n\n**Adversarial AI agents:** As AI agents become more capable and more prevalent in enterprise environments, using them as attack vectors becomes more attractive. A compromised or manipulated AI agent with legitimate credentials can do significant damage quietly.\n\n**LLM-specific attacks against your own AI systems:** If you're running internal LLMs or using AI services that ingest internal data, adversarial inputs designed to exfiltrate data or manipulate outputs become a real concern.\n\n* * *\n\n## Practical Steps for CISOs and Security Teams Today\n\nThe AI security problem can feel overwhelming - too many new threat vectors, too few proven defenses. Here's a practical prioritization.\n\n**This quarter:**\n\n  * Inventory all AI tools and services currently in use across the organization (the number is higher than IT knows)\n  * Audit all service accounts and API keys associated with AI workloads; revoke anything not actively used\n  * Implement conditional access policies that apply specifically to AI service accounts\n  * Define acceptable-use policy for AI tools and communicate it explicitly\n\n\n\n**This year:**\n\n  * Implement workload identity management for AI agents you develop or deploy\n  * Establish agent-specific logging and build initial behavioral baselines\n  * Design human-in-the-loop controls for irreversible agent actions\n  * Conduct a prompt injection threat assessment for any internal LLM deployments\n  * Extend your access certification process to cover AI tool authorizations\n\n\n\n**Ongoing:**\n\n  * Treat AI agent identity with the same rigor as privileged human identity\n  * Incorporate AI attack scenarios into red team exercises\n  * Stay current with emerging standards (the OAuth working group is actively developing workload identity extensions; NIST is updating SP 800-207 guidance to incorporate AI considerations)\n\n\n\n* * *\n\n## The Core Insight\n\nZero Trust's founding insight - that implicit trust based on network location is the fundamental flaw in enterprise security - applies with equal force to AI agents and machine identities.\n\nThe extension for the AI era is this: trust shouldn't be implicit based on _any_ identity signal, human or machine. Every access request should be verified against explicit policy. Every identity should carry only the minimum permissions needed. Every system should be designed assuming that any component can be compromised.\n\nAI doesn't break Zero Trust. But it does expose the parts of Zero Trust that most organizations implemented incompletely. Machine identity governance, east-west traffic control, behavioral analytics for non-human entities - these were always part of a complete Zero Trust architecture.\n\nThe AI era just makes it urgent to get them right.\n\n* * *\n\n_Deepak Gupta_ _is the Co-founder & CEO of GrackerAI and an AI & Cybersecurity expert with 15+ years in digital identity and enterprise security. He writes about cybersecurity, AI, and B2B SaaS at guptadeepak.com._",
  "title": "Zero Trust in the Age of AI: Why the Classic Model Isn't Enough Anymore",
  "updatedAt": "2026-03-05T16:40:39.152Z"
}