Your security team just approved an AI coding assistant for your engineering team. Within days, developers are using it to refactor authentication logic, query production databases, and push code changes. When you ask about access controls, you hear: "It's fine—the AI only does what we tell it to."
This is when myths about AI agent security become expensive problems.
The release of IronCurtain—an open-source policy engine that intercepts and evaluates AI tool calls before execution—exposes how little most teams understand about controlling autonomous agents. IronCurtain uses a policy engine to decide whether AI tool-call requests should be allowed, denied, or escalated, working from a "constitution" written in plain English by the user. But the tool's existence highlights a bigger issue: most security teams are operating on outdated assumptions about how AI agents work and what "control" actually means.
Here are five myths that persist because they feel intuitive—and why they're wrong.
Myth 1: "Prompt engineering is sufficient access control"
Reality: Prompts are instructions, not security boundaries.
Your developers write careful prompts: "Only modify files in the /src directory" or "Never delete production data." They assume the AI will follow these rules like a junior engineer would follow a runbook.
This conflates two different concepts. A prompt shapes behavior through suggestion. An access control policy enforces boundaries through technical restriction. When you tell an AI agent "don't access the database," you're hoping it understands and complies. When you implement a policy that denies database tool calls, you're preventing the action regardless of what the agent intends.
The difference matters because AI agents don't have intent—they have probability distributions. An agent might interpret "only modify src files" as permission to read configuration files in /config if the context suggests it's helpful. Or it might decide that deleting a temporary table in production doesn't count as "deleting production data" because it's marked as temporary.
IronCurtain's approach—intercepting tool calls and evaluating them against explicit policies before execution—treats AI agents like any other untrusted process. You wouldn't let a third-party service access your infrastructure just because it promised to be careful. Apply the same principle to AI.
Myth 2: "We can review AI actions after the fact"
Reality: Post-execution logging doesn't stop the damage.
Many teams implement AI observability platforms that log every action an agent takes. They treat this as a security control: "If something goes wrong, we'll see it in the logs and roll back."
This is detection, not prevention. By the time you're reviewing logs, your AI agent has already executed the API call that exposed customer data, deleted the critical file, or modified the production configuration. Your incident response playbook now includes "AI agent made unauthorized change"—which means you've already failed.
The policy engine model that IronCurtain demonstrates evaluates actions before execution. Each tool call—whether it's reading a file, executing a command, or making an API request—gets evaluated against your defined policies. Actions that violate policy get blocked or escalated for human review before they happen.
Consider what this means for compliance. PCI DSS v4.0.1 Requirement 6.4.3 mandates that you validate all inputs to your application. If your AI agent is making API calls or database queries based on natural language input, those queries need validation before execution—not after. Logging alone doesn't satisfy this requirement.
Myth 3: "The AI vendor handles security for us"
Reality: Vendors secure their infrastructure, not your policies.
Your AI vendor ensures their model endpoints are protected, their training data is isolated, and their API keys are rotated. This is necessary but insufficient.
What the vendor doesn't know: which files in your repository contain secrets, which API endpoints should never be called from development environments, or which database tables are subject to GDPR deletion requirements. These are your policies, and they need to be enforced at your boundary—between the AI agent and your tools.
The Model Context Protocol (MCP), which IronCurtain uses to manage AI tool interactions, provides a standardization layer. But standardization of the interface doesn't mean standardization of policy. You still need to define what "allowed" means in your environment.
This is analogous to how you handle third-party integrations. Your SaaS vendor secures their application, but you still implement SAML assertions, scope OAuth permissions, and restrict API access based on your requirements. AI agents need the same treatment.
Myth 4: "Open-source AI security tools are less secure than commercial solutions"
Reality: Open-source security tooling enables verification that commercial products can't provide.
Some teams avoid open-source security tools because they assume commercial vendors provide better security guarantees. For AI agent controls specifically, this logic inverts.
When you implement a policy engine that sits between your AI agent and your infrastructure, you need to verify that the engine itself isn't introducing vulnerabilities. Can the AI agent bypass the policy check? Can it manipulate the policy evaluation? Does the engine properly isolate policy decisions from the agent's context?
With IronCurtain's open-source approach, you can audit the policy evaluation logic, verify that tool calls are actually intercepted, and confirm that the constitution-to-policy translation works as expected. You can run it in your own environment without sending your policy definitions or tool call data to an external service.
For compliance frameworks like SOC 2 Type II, this matters. When your auditor asks how you ensure AI agents comply with your access controls, "we use a commercial black box that promises it works" is a weaker answer than "we use a policy engine we've audited and verified."
Myth 5: "Natural language policies are too imprecise for security"
Reality: The translation layer is the security control, not the language.
IronCurtain's policy engine relies on a constitution written in plain English by the user. Some security engineers see this and assume it's too loose—that security policies need to be written in formal policy languages with explicit deny rules.
But the natural language interface isn't the enforcement mechanism—it's the input format. The policy engine translates your English-language constitution into enforceable rules. The question isn't whether English is precise enough; it's whether the translation is correct and auditable.
This is actually an advantage for most teams. Your security policies already exist in English: "Developers can't access production databases directly" or "All API calls to payment processors require approval." Converting these to formal policy languages creates translation errors and maintenance burden. If your policy engine can take your existing policy language and enforce it accurately, you've reduced the gap between policy and implementation.
The verification requirement still applies: you need to test that your natural language policy produces the expected allow/deny decisions. But this is testing, not a fundamental limitation of the approach.
What to Do Instead
Stop treating AI agents as helpful assistants that will follow your rules. Start treating them as untrusted processes that need technical controls.
Implement policy enforcement at the tool call boundary. Before your AI agent can execute a file operation, API call, or database query, that action should be evaluated against your access policies. Tools like IronCurtain provide this interception layer—use them or build equivalent controls.
Define your policies in the same language you use for other access controls. If your existing security policies say "no production database access from development environments," your AI agent policies should enforce the same rule. Don't create a separate, looser set of standards just because the requester is an AI.
Test your policy enforcement with the same rigor you apply to authentication systems. Can an AI agent craft a prompt that bypasses your policy? Can it use tool chaining to achieve a denied outcome through allowed intermediate steps? Run these tests before your developers deploy agents into production workflows.
Your AI agents will execute thousands of tool calls. Make sure you've decided—in advance, with technical controls—which ones are allowed.
AI security guidelines
