By Sanket Naik [Founder & CEO, Palosade]
Over the past several months I’ve been co-leading the Enterprise AI Governance track at the Purple Book Community’s AI Center of Excellence. It’s a working group of security practitioners who meet regularly to compare notes on what actually holds up when you try to secure AI agents in production. This week we published the result: Securing AI Agents in the Enterprise: A Practitioner’s Guide (v1.0, July 2026), co-authored with Mohit Bansal, Shivageeta Choodi, Bill Tamerlane, Anisha Tekwani, and Vikrant Waghmode, with input from fifteen additional practitioners across the community.
I want to use this post to pull out the parts of the guide that surprised me, because they run against how most security teams still frame this problem.
The gap that motivated the work
The whitepaper opens with two numbers that explain why this work happened: in a 2026 survey, 60% of CEOs said they were intentionally slowing AI implementation over concerns about errors and malfunctions, while only 21% of organizations report having a mature model for governing the agents they’ve already deployed. Leadership is nervous, and the governance needed to justify confidence isn’t there yet. The cohort spent the year trying to close that gap with something more concrete than “adopt a framework.”
Security architecture is now a token-cost problem
Practitioners in the cohort don’t treat token economics as a budgeting afterthought. They treat it as a design constraint that determines the security architecture itself. Continuous model-based analysis is expensive enough that teams can only afford to run as much of it as their budget allows, so the boundary between deterministic tooling and model-based analysis is set by cost, not by which one is theoretically more thorough.
The practical consequence is a hybrid architecture, and it’s more prescriptive than it sounds. Deterministic tools enforce the high-frequency, must-hold security boundaries: SAST, SCA, allow-lists, policy enforcement, sandboxing. They’re cheap, fast, and don’t degrade under adversarial pressure. Model-based reasoning gets reserved for the narrow set of tasks where it adds measurable value: correlating signals across tools, triaging what the deterministic scanners already flagged, catching patterns that can’t be written as rules. Teams that skip this and lean on model judgment for boundary enforcement are making a cost decision disguised as a security decision, whether they realize it or not.
Detection-based prompt injection defense doesn’t work
One study the group cites found that twelve published prompt-injection and jailbreak defenses could be bypassed at rates above 90% under adaptive attack. The guide doesn’t argue for better detection. It argues that filtering alone isn’t reliable enough to serve as the security boundary. Agents need to be structurally contained, not just screened.
The structural fix is the “lethal trifecta” rule: an agent becomes dangerous the moment it holds all three of private data access, exposure to untrusted content, and the ability to communicate externally. The rule of thumb practitioners apply is to never let a single agent or session hold more than two of the three. When a task needs all three, it gets routed through human approval or a separate, isolated step instead of a smarter filter.
This same skepticism extends to guardrail files. A CLAUDE.md-style file that constrains what an agent can touch is the most frequently cited control in the guide, and it’s a good one. It also happens to reduce token spend by bounding scope. But the guide is explicit that it’s necessary and not sufficient, because a model under adversarial pressure can disregard its own instructions. The file has to be paired with enforcement that sits outside the model entirely: allow-lists, sandboxes, and hooks that block disallowed actions regardless of what the model decides to do.
Identity models built for humans don’t work for agents
OAuth and OIDC assume a human is present to grant consent, which means an agent operating on a long-lived token can keep acting long after the user’s actual intent has expired. The guide’s practitioners are moving toward intent-bound authorization instead: short-lived, task-scoped credentials evaluated at the moment of each tool call, with delegation chains that are traceable end-to-end so a sub-agent’s authority is a provable subset of whatever spawned it. It’s a meaningfully different model from “grant the service account broad access and rotate the key occasionally,” and most identity stacks aren’t built for it yet.
Where the guide tells teams to start
The full roadmap has seven steps, but the sequencing itself is the useful part: establish the guardrails file first, then get deterministic scanning running before reaching for model-based analysis, segment agents by function before doing anything else architectural, and only then move to intent-bound authorization, data-flow auditing, agent inventory, and framework selection. The order matters because each step reduces the blast radius of the ones that come after it. Segmenting agents by function, for instance, is what makes the later authorization work tractable instead of theoretical.
On frameworks specifically, the guide argues against chasing all of them. It recommends anchoring to a small set applied in order of increasing commitment: OWASP’s LLM Top 10, then its Agentic Applications Top 10, then AISVS to make those risks testable, treating the rest as reference material rather than adoption targets. If your organization already runs HITRUST or FedRAMP, extend that program rather than starting a parallel one; both have AI-relevant extensions built on infrastructure you already have.
What the cohort still hasn’t solved
Most vendor content in this space implies the problem is further along than it actually is. This guide is more honest about that: it closes with an explicit list of open questions the cohort didn’t resolve. Two stood out to me. Nobody in the group has found a dependable method yet for discovering shadow agents or attributing an agent’s actions back to an accountable owner; inventory and observability are still treated as an open identity problem. On the supply-chain side, there’s no vetted public registry for guardrail files or agent skills, so the group’s working guidance is to treat any public skill or guardrail source as untrusted until proven otherwise. That’s a more cautious stance than most teams currently take.
Where this lands for us at Palosade
The whitepaper’s central architectural argument is the same hybrid posture we build to at Palosade: deterministic controls for the high-frequency security boundaries, model reasoning reserved for the correlation and triage work that rules can’t express. Our agents don’t get trusted by default. Outputs are grounded in a customer-specific security context graph and checked through evals and human-in-the-loop validation. Findings map back to the frameworks security teams already answer to (OWASP, NIST, MITRE, CSA), with an audit trail behind each one. We don’t expect anyone to take that on faith. It’s the same standard the cohort arrived at independently for agent security in general — trust earned through mechanism rather than assertion.
The guide itself
Securing AI Agents in the Enterprise: A Practitioner’s Guide is a living document; the Purple Book Community plans to review and update it quarterly as the threat landscape and standards shift. You can read the full guide here: Securing AI Agents in the Enterprise — A Practitioner’s Guide.
If you’d rather watch than read, I moderated a companion panel on the same findings, recorded for PBC Connect at RSAC 2026: agent permissions and delegation, where the security frameworks actually help, and the cost and governance trade-offs teams are working through. Watch it on the Purple Book Community or on YouTube.
About Palosade:
Palosade provides AI agents for modern DevSecOps empowering businesses to embrace the product velocity enabled by AI while meeting regulatory and customer security requirements. These AI agents are built on Palosade AI agent platform, purpose-built for security, with enterprise-grade features and guardrails to guarantee accuracy, consistency, reliability, and auditability. Common use cases include security design review, security code review, threat modeling, threat intelligence, and compliance.
Learn more at www.Palosade.com, follow us on LinkedIn , and join the Palosade Community on Slack.
