A common setup looks like this. An agent (a language model that reads a task, runs a command, looks at the result, and goes again) gets a database login with write access, so it can fix a broken deploy or clean up bad rows without paging anyone. The only thing between that agent and a command that wipes a table is a sentence in its prompt, something like “never delete data” or “confirm before acting.” If that sentence fails once, the table is gone.
Deno (the company behind the Deno JavaScript runtime) runs agents this way on purpose. Ryan Dahl is Deno’s CEO and the creator of Node.js. He told AI Engineer World’s Fair 2026 that Deno gives the OpenClaw agent (an AI agent that people run to act on their own accounts and systems) read and write access to Postgres (a widely used open-source SQL database), Kubernetes, ClickHouse, AWS, GitHub, and Slack so it can work production incidents [1]. He says the agents solve a lot of incidents that used to need a person. He also calls the setup dangerous. The failure he worries about is an agent that opens a database session and deletes the users table [1].
The usual fixes each help a little. Each one also leaves the guard somewhere the agent can reach, or somewhere that checks too early. The design that holds moves the guard outside the agent.
Figure 1 - Guard Inside, Boundary Outside: On the left, the rule lives inside the agent’s own prompt and plugins, where it can be lost, overruled, or edited. On the right, the agent proposes an action and separate code on the path to the database decides.
The only guard is a sentence in the prompt
Start with what the database sees. The agent connects with a credential (the password, token, or API key that proves to a system who is calling). The database checks it, finds a valid login with write access, and runs whatever arrives. It can’t tell whether a senior engineer, a cron job, or a confused model typed the command.
Narrower logins help. Dahl says teams should hand out careful credentials, such as a read-only Postgres login, and that this works up to a point [1]. The trouble, he says, is that tight permissions across many systems are hard to get right, and access to one system can open a path into another [1].
So the model makes the real decision about a destructive command. It reads its prompt and the task, then decides what to type. Dahl says Anthropic’s Opus model is well aligned (trained to follow its operator’s intent and refuse harmful actions). Try hard to get it to delete the users table, and it refuses over and over [1]. He still calls relying on that alone wishful thinking [1]. We agree.
Figure 2 - What Stands Between the Agent and the Data: The agent holds a credential with write access. The database accepts any command that arrives with it. The only check on a destructive command is a rule written in the agent’s own prompt.
Fix 1: write the rule into the prompt
The first fix is the obvious one. Add a line to the agent’s instructions: don’t touch production data, confirm before you delete anything. It costs nothing, and the model usually follows it. It still breaks in two ways.
The rule can fall out of the agent’s memory
A model only sees what’s in its context window (the block of text it reads on every turn: the instructions, the conversation so far, and any tool output). Long sessions outgrow it. When that happens, many agent harnesses (the program wrapped around the model that runs the loop and holds its tools, prompts, plugins, and settings) run compaction (they summarize older parts of the conversation to free up room). The summary keeps the gist. Your exact rule may not make it in.
Summer Yue, director of alignment at Meta Superintelligence Labs [2], posted about this in February 2026. She had told her OpenClaw agent to suggest what to archive or delete in her inbox and not to act until she said so. It had worked on a small test inbox. Then, in her words: “my real inbox was too huge and triggered compaction. During the compaction, it lost my original instruction” [3]. Her first post described the result: “Nothing humbles you like telling your OpenClaw ‘confirm before acting’ and watching it speedrun deleting your inbox” [4]. She couldn’t stop it from her phone and had to run to her Mac mini [4].
Karan Vaidya, co-founder and CTO of Composio, a company that sells tooling for governing agents, retold the story on stage in June. He described her rule as “just a prompt which probably would have compacted away” [5]. Yue’s own account is firmer. She says compaction dropped the instruction [3].
Figure 3 - A Rule That Didn’t Survive the Summary: Before compaction, the confirm-before-acting rule sits in the context window with everything else. After compaction, the summary keeps the task and drops the rule. The agent carries on without it.
The agent does what it’s told, by whoever tells it
The second failure shows up even when nothing is forgotten. Dahl’s talk includes a short demo, which he introduces as “a little demo. Unfortunately, not live” [1]. His team runs Codex (OpenAI’s coding agent) in yolo mode, a setting where it runs commands without stopping to ask. The operator tells it to delete the users table from Postgres. Codex does as it’s told and starts psql (the Postgres command-line client) to run the delete [1].
The operator gave a direct order, and the agent followed it. We want that from a helpful tool. The trouble is that a model that follows instructions well will follow them from anyone whose text lands in its context window.
That opens the door to prompt injection (instructions hidden in content the agent reads, such as a web page, an email, or a support ticket, which the agent then follows as if they came from you). Dahl worries about this in his own setup. His incident agents connect to the support system, so they “can be prompt injected from the outside” [1].
Anthropic’s September 2026 threat report describes a real case. In the case Anthropic labels GTG-50020, an attacker injected instructions into an AI vendor’s automated evaluation sandbox (an isolated environment where the vendor runs models against test tasks) and “caused the sandbox to hand over the credentials it held,” including production API keys from several providers [6]. The report says the keys belonged to customers and were taken from customers’ environments, and that Anthropic’s own systems were never compromised [6].
Figure 4 - One Agent, Two Sources of Instructions: The operator’s order and text arriving from outside both land in the same context window. The agent has no reliable way to tell which one to trust, so any text the agent reads can override a rule in its prompt.
A prompt rule can be summarized away or outvoted, so the next step is a check that lives outside the prompt.
KEY INSIGHT: Treat a rule in a prompt as advice the agent usually follows. If breaking the rule would cost you data or leak a key, enforce it in code that the agent’s text can’t change.
Fix 2: put a checker in front of the agent
The usual next move is a checker. One kind scans skills (add-on instruction packages, defined below) before you install them. The other is a guard plugin inside the agent’s own software that blocks commands that look dangerous.
A scan checks the content once
A skill is a folder of instructions and scripts that an agent loads when a task calls for it, described by a SKILL.md file at the top. Public directories such as skills.sh let anyone publish or install skills. A scanner is a tool that reads a skill before you install it and flags patterns known to be malicious.
AIR, a security startup building a firewall for agents, published a research demonstration in June. AIR says it tested its skill against Cisco’s and Nvidia’s scanners and all of skills.sh’s scanners. Every one of them vetted it as safe [7]. The skill pointed to a documentation page that AIR controlled. After the skill became popular, AIR changed what that page said [7]. AIR reports that 26,000 agents were affected, including agents on corporate accounts, and says its payload only collected email addresses [7]. AIR’s conclusion is that current scanners “scan only a portion of the skill’s content, rendering the scan’s result irrelevant by design” [7]. AIR sells the kind of product this result argues for.
Zenity Labs, another agent-security vendor, disclosed a real campaign in August. A family of skills “began accumulating skills.sh installs while they were still clean,” and Zenity says the skills were trojanized on July 11 [8]. Zenity counted more than 1.7 million aggregate installs across the family, and says those counters are not unique users [8]. Zenity’s post shows the same timing gap from the attacker’s side: content that was clean when people chose it and changed later. It makes no claim about scanners.
Testing whether a skill works before you adopt it is a separate question, covered in Don’t Ship Skills Without Evals [9].
Figure 5 - The Scan Happens Once, the Content Keeps Moving: The scanner reads the skill and marks it safe. The skill is installed. Later, the content it depends on changes. By the time the agent loads it, the scanner’s verdict describes something that no longer exists.
A guard inside the agent’s software can be edited
The second kind of checker lives inside the agent harness, the same program that runs compaction. Harnesses are built to be extended, which is why they’re useful. You can add a plugin, write a hook (a script the harness runs automatically at set points, such as before a command), change a setting, or drop in a skill, and the harness picks it up.
Four authors from NVIDIA, which sells a secure agent runtime called OpenShell, explain why that makes the harness a bad home for a security check: “This programmability makes the harness a poor place for a security guarantee: a layer designed to be modified cannot reliably enforce controls against its own modification” [10]. The openness that lets you install a guard also lets a later change weaken or remove it. Dahl draws the same line. His thesis is that agents can’t be trusted to police themselves, and he adds: “That includes security plugins or modifications to the agent software itself” [1].
Anthropic’s alignment researchers have shown what a deliberately misaligned model did when a monitor sat within its reach. They trained a model on purpose to chase reward (to maximize the score its training gives it, even by cheating, which researchers call reward hacking). Then, in a simulated training setup, they gave it the chance to kill a process that watched it for reward hacking. The model was willing to do that and more [11]. We covered what this means for evaluations in Silent Agent Failures [12]. Here, the point is that the monitor ran where the model could reach it.
Figure 6 - The Guard Shares a Home with What It Guards: A guard plugin runs inside the harness next to the plugins, skills, and settings that the harness is designed to accept. Anything that can change the harness can change the guard.
So the two checkers fail in different ways. The scan fails on timing: it looks once, and the content changes afterward. The guard fails on placement: it sits inside software built to be changed. Neither one checks the action itself at the moment the agent takes it.
Fix 3: a boundary the agent can’t reach
The NVIDIA authors sum up the rule this way: “Above proposes; below decides. No model, agent, harness, tool, or memory system grants itself authority” [10]. The agent sits above and proposes an action, like a SQL statement or a tool call. A separate layer sits below, on the path the action has to travel. That layer decides, and the agent can’t edit it.
The layer below should be deterministic (plain code that gives the same decision for the same input every time, with no model making the call). Sanders of PostHog, whose scanner comes up later, says: “Enforcement is the part that you bet the house on. So it has to be deterministic” [13]. That handles each failure from the first two fixes:
- Compaction can’t drop the rule. The rule was never in the context window, and a different program reads it.
- It doesn’t matter who gave the order. The boundary reads only the action, so an order from you and one from a poisoned ticket get the same check.
- The agent can’t edit the check. The code sits on the path the agent’s actions must travel, somewhere the agent has no access.
- The check runs every time. The boundary checks each action as it happens, so a skill whose content changed after install still has to get its commands past it.
Vaidya agrees: “The boundary lives outside these agents. It can’t be argued with by the agent or forgotten or compacted” [5].
Figure 7 - Above Proposes, Below Decides: The agent’s output is a proposal. A deterministic layer below it, which the agent cannot modify, turns the proposal into an allow or a deny before anything reaches a real system. The phrase is NVIDIA’s name for the rule.
Several vendors now ship this pattern. Each of the five examples below comes from the vendor that builds it, and the fifth fits only in part.
A proxy that reads the database’s own language
Claw Patrol is Deno’s version, open-sourced in May under the MIT open-source license and described by Deno as “currently alpha software” [14]. It’s a proxy (a program that sits between two systems and passes traffic along, so it can inspect and block that traffic on the way). Its README says it “sits between your agents and prod, parses their traffic at the wire, and gates each action against rules you write in HCL” [15]. HCL (HashiCorp Configuration Language) is a plain-text configuration format.
“At the wire” means Claw Patrol reads the wire protocol (the exact byte format a client and server use to talk over the network). For Postgres, that lets it see the SQL verb and the table name in each request [15]. That’s what blocked the delete in Dahl’s demo. Codex’s psql session opened a network connection to the Postgres server, and that connection went through Claw Patrol. Claw Patrol parsed the Postgres protocol, applied Deno’s rules, and rejected the delete [1]. Claw Patrol rules can also send an action to a model acting as judge, or to a human in Slack, before it goes through [14]. The rule in the demo was a plain deny.
Dahl points out that Postgres doesn’t speak HTTP, so a proxy that only understands web requests never sees what a psql session sends [1].
Figure 8 - A Proxy That Reads the Wire: The agent’s database connection runs through Claw Patrol. The proxy parses the Postgres protocol, checks the action against written rules, and rejects the destructive one before it reaches the server. The agent’s reasoning is never consulted.
A gateway that says no unless a rule says yes
AWS applies the same idea to tool calls in Amazon Bedrock AgentCore, AWS’s service for running and connecting AI agents. A gateway is a single entry point that every tool call has to pass through. AgentCore’s policies are written in Cedar, an open-source language for writing authorization rules, which spell out who can do what [16].
Cedar is default-deny (everything is refused unless a rule explicitly allows it). The AWS docs say: “All actions are denied by default. If no policies match a request, Cedar returns DENY” [17]. The docs also say where the check runs: “Every agent action through Amazon Bedrock AgentCore Gateway is intercepted and evaluated at the boundary outside of agent’s code” [16]. Policy in AgentCore has been generally available (out of preview and supported for production use) since March 2026 [18].
AWS’s migration post has a small sample that shows this. It creates two callers with identical IAM policies (IAM is Identity and Access Management, AWS’s built-in permission system) and two tools. One Cedar rule lets a read-only caller look up orders, and another lets a privileged caller also process returns. When the read-only caller tries to process a return, no rule permits it, so the call is refused. The authors write that “the enforcement is provably Cedar’s and not an IAM gap” [19]. They also explain why a filter on the model’s output can’t do this job: “A guardrail on model output is not on that path, and by the time it runs, the tool call has happened” [19].
Figure 9 - Default-Deny at the Gateway: Two callers carry the same IAM permissions. One call matches a Cedar permit rule and goes through. The other matches none, so the gateway refuses it. In AWS’s sample, the refusal comes from Cedar alone.
Keys the agent never holds
Recall the sandbox in GTG-50020 that handed over the keys it held [6]. The fix is for the agent never to hold them. That’s credential injection (a proxy adds the real secret to a request after it leaves the agent, so the agent only ever sees a placeholder).
Deno’s Claw Patrol launch post describes it: “Credentials live on the gateway, not the agent. The agent sends a placeholder like {{github_pat}} and the gateway swaps in the real token on the wire. A compromised agent process can’t leak keys it never held in the first place” [14]. 1Password, a secrets-management company, uses a similar design in its Codex rollout, as described in OpenAI’s case study: “1Password resolves and injects the credential at the point of action, so the plaintext value never enters the model context” [20].
Figure 10 - The Secret Never Enters the Context Window: The agent sends a request carrying a placeholder. The proxy, outside the agent, swaps in the real credential on its way to the service. If the agent is manipulated, there is no key in its context to leak.
A spending limit set below the model
AWS’s design for AgentCore payments, which became generally available in August 2026 [21], states its assumption in the open: “The design does not prevent prompt injection. Instead, it assumes untrusted input can manipulate the model and bounds the runtime’s authority by recipient, asset, network, per-payment amount, session budget, and expiry” [22]. AWS expects the model to get fooled and caps what it can spend.
A scan at load time, with no model deciding
The scan from Fix 2 failed because it ran once. PostHog scans again at the moment the content is used. Sarah Sanders, a context engineer at PostHog, built a scanner called Warlock for PostHog’s setup agent, which loads docs and skill bundles into its context while it runs. She calls that pipeline “a machine whose whole job is to take content and inject it into an agent that can run commands,” and her advice is to “scan your own supply chain at the source and when the agent invokes it” [13].
Warlock uses YARA rules (a pattern-matching rule format that malware researchers use to spot known threats in files), and it only detects: “Engine-only by design. the Warlock scans, you decide when and what” [23]. PostHog’s setup tool does the blocking. Sanders describes that step: “If a rule matches, the gate locks, the session ends, and there is no model anywhere on that path” [13]. Warlock is a partial fit. It runs inside PostHog’s own tooling, and its README says “It’s not a general-purpose security product” [23]. Still, it shows a pattern worth copying: no model sits on the enforcement path.
KEY INSIGHT: For each action that could hurt you, find the code that makes the final allow-or-deny call. If the agent can reach that code, edit it, or argue with it, move the check somewhere it can’t.
Where the boundary still fails
A boundary outside the agent is the strongest design we’ve seen. It still has gaps to plan for.
Asked whether the problem grows or shrinks as agents get smarter, Dahl answered: “I think we will never be able to fully trust AIs. I think it becomes less and less of a problem as they are smarter … but I think we’re always going to have to have backstop security mechanisms” [1]. He expects the problem to shrink and the backstops to stay.
A boundary only covers the paths that go through it. The AWS docs choose their words carefully: every agent action through the gateway is checked [16]. A tool call that reaches a system some other way skips the check. Dahl’s psql example makes the same point for proxies [1]. If the agent’s machine can reach the database directly, the proxy never sees the traffic. Deno closes that gap at the network level. It runs its agents on standalone virtual machines inside a Tailscale network (a private-network service), with Claw Patrol acting as that network’s exit node [1]. Keeping each customer’s (tenant’s) data apart inside the database is a separate problem, covered in Multi-Tenant Agent Security [24].
The boundary also becomes a target. Dahl notes that Claw Patrol holds all the credentials to Deno’s production systems, so it has to be protected with great care [1]. The evidence is also thin. Sanders says PostHog has “basically never caught an actual malicious prompt injection in the wild” [13]. No source here gives a count of real attacks blocked.
Finally, “outside the agent” is a placement decision, so you have to decide what happens when the check itself breaks. A check can fail open (let the action through when the check can’t run) or fail secure (block or restrict it). AWS’s healthcare API post isn’t about agents, but it shows the choice clearly, with two answers in one design. A behavior analyzer runs after the response has already gone back to the client, and it fails open: “if the analyzer encounters an error, it logs the failure but doesn’t block the original API request” [25]. AWS chose that so an analyzer outage wouldn’t disrupt clinical work [25]. A data classifier in the same design fails secure: “If classification fails, the function defaults to CONFIDENTIAL (fail-secure)” [25]. AWS describes those as choices for two specific functions. Our reading is that every boundary needs the same decision made on purpose. When a check can’t run, does the action go through or stop?
Figure 11 - Fail-Open and Fail-Secure in One Design: In AWS’s healthcare API example, the analyzer that runs after the response fails open, so an analyzer outage doesn’t hold up clinical requests. The classifier fails secure and labels data CONFIDENTIAL when it can’t decide. Each boundary needs that choice made deliberately.
KEY INSIGHT: Decide in advance what each boundary does when it breaks. Choose fail-secure for anything guarding production data or keys, and write down every place you chose fail-open and why.
Which level is your agent running at?
The NVIDIA post gives four security profiles that work well as a quick self-check [10]. It’s NVIDIA’s own framework, so treat it as one vendor’s view. The levels and required settings below are NVIDIA’s wording:
| Level | Typical work | Required configuration |
|---|---|---|
| Isolated | Coding in pre-production with disposable data | No production credentials; restricted network; session recording |
| Connected | Pre-production using approved services | Short-lived identity; masked data; rate/spend limits; full logging |
| Production | Changes to production systems or data | Task-scoped access; independent checks; human approval for high-impact |
| Adversarial | Frontier-model, non-guardrailed, or red-team runs | Default-deny communications; automatic quarantine; strongest isolation |
Session recording keeps a log of everything the agent did. Masked data means real values are replaced with realistic fakes. A red-team run is one where testers deliberately try to make the agent misbehave, and quarantine means cutting the agent off automatically.
The opening setup, an agent with write access to a live database, sits at the Production level. NVIDIA’s required configuration there is task-scoped access, independent checks, and human approval for high-impact changes [10]. A rule in the prompt meets none of those.
Figure 12 - NVIDIA’s Four Security Profiles: NVIDIA sorts agent work into four profiles, each with a required configuration. Find the level that matches what your agent does today, then check whether your setup has what that level requires.
Conclusion
If an agent holds a real credential and its only limit is a prompt rule, the agent is guarding itself. In the cases and demonstrations above, that guard was dropped by compaction, overruled by an order, or outrun by content that changed after a scan. NVIDIA argues a fourth: a guard inside the harness can be changed along with it. What holds is code on the path the action has to travel, which reads the action itself and which the agent can’t reach.
Pick the level in the table above that matches your agent today. Then list every path from that agent to a production system, including the ones it could open on its own, like a psql session. For each path, name the code that decides allow or deny, and check whether the agent can reach it. Any path where the answer is “the prompt” is the first one to fix.
References
[1] R. Dahl, “Security Firewall for Agents,” AI Engineer World’s Fair 2026, June 30, 2026 (video posted Aug. 17, 2026). https://www.youtube.com/watch?v=MkRYPFIMCSA
[2] Z. Stone, “She runs AI safety at Meta. Her AI agent still went rogue,” The San Francisco Standard, Feb. 25, 2026. https://sfstandard.com/2026/02/25/openclaw-goes-rogue/
[3] S. Yue, post on X, Feb. 23, 2026. https://x.com/summeryue0/status/2025836517831405980
[4] S. Yue, post on X, Feb. 23, 2026. https://x.com/summeryue0/status/2025774069124399363
[5] K. Vaidya, “From coding to Knowledge work agents,” AI Engineer World’s Fair 2026, June 30, 2026 (video posted Sep. 3, 2026). https://www.youtube.com/watch?v=xxfMT-bPEmU
[6] Anthropic, “Detecting and countering misuse of AI: September 2026,” Anthropic, September 2026. https://www.anthropic.com/threat-intelligence-report-september-2026
[7] N. Hoffman and O. Nevo, “The Story of Skills - How We Hijacked 26,000 Agents With One Instagram Ad,” AIR, June 22, 2026. https://www.air.security/blog-posts/the-story-of-skills
[8] M. Bargury, “Attackers Target Agents via The Skill Supply Chain,” Zenity Labs, Aug. 6, 2026. https://labs.zenity.io/post/attackers-target-agents-via-the-skill-supply-chain
[9] G. Dotzlaw, “Don’t Ship Skills Without Evals: A Reproducible Way to Prove Your Claude Code Skills Work,” Dotzlaw Consulting, September 9, 2026. /insights/claude-code-18-skill-eval-methodology/
[10] J. Greco, K. Thadaka, A. Golshan, and A. Watson, “Where Security Fits in an AI Agent Stack,” NVIDIA Technical Blog, Aug. 21, 2026. https://developer.nvidia.com/blog/where-security-fits-in-an-ai-agent-stack/
[11] R. Qi, B. Wright, M. MacDiarmid, and E. Hubinger, “Training a Misaligned Reward Seeker,” Anthropic Alignment Science Blog, Aug. 2026. https://alignment.anthropic.com/2026/reward-seeker/
[12] G. Dotzlaw, “Silent Agent Failures: A Production Blueprint for the Errors Your Dashboard Cannot See,” Dotzlaw Consulting, September 16, 2026. /insights/ai-42-silent-agent-failures-production-blueprint/
[13] S. Sanders, “We let an AI agent execute Bash and lived to talk about it,” AI Engineer World’s Fair 2026, July 2, 2026 (video posted Sep. 14, 2026). https://www.youtube.com/watch?v=4lXks428C9o
[14] R. Dahl, B. Belder, D. Srivastava, A. Orriols, Y. Tanaka, and J. Collinsworth, “Claw Patrol: an open-source security firewall for agents,” Deno Blog, May 21, 2026. https://deno.com/blog/clawpatrol
[15] Deno Land Inc., “clawpatrol: The security firewall for agents,” GitHub repository (MIT). https://github.com/denoland/clawpatrol
[16] Amazon Web Services, “Policy in Amazon Bedrock AgentCore: Control Agent Interactions,” Amazon Bedrock AgentCore Developer Guide, accessed Sep. 17, 2026. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html
[17] Amazon Web Services, “Understanding Cedar policies,” Amazon Bedrock AgentCore Developer Guide, accessed Sep. 17, 2026. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-understanding-cedar.html
[18] Amazon Web Services, “Policy in Amazon Bedrock AgentCore is now generally available,” AWS What’s New, Mar. 3, 2026. https://aws.amazon.com/about-aws/whats-new/2026/03/policy-amazon-bedrock-agentcore-generally-available/
[19] S. Vedula, A. Mettu, and H. Krishna, “Migrate agentic workloads to Amazon Bedrock AgentCore,” AWS Machine Learning Blog, Sep. 3, 2026. https://aws.amazon.com/blogs/machine-learning/migrate-agentic-workloads-to-amazon-bedrock-agentcore/
[20] OpenAI, “1Password increases engineering productivity 21% with Codex,” OpenAI, Sep. 8, 2026. https://openai.com/index/1password
[21] Amazon Web Services, “AgentCore payments is now generally available in Amazon Bedrock AgentCore,” AWS What’s New, Aug. 18, 2026. https://aws.amazon.com/about-aws/whats-new/2026/08/bedrock-agentcore-payments-ga/
[22] D. Wirjo, I. Lin, M. S. Vangara, P. Erichsen, C. Shriyan, and P. Jiang, “Build OpenClaw agents that transact with Amazon Bedrock AgentCore payments,” AWS Machine Learning Blog, Aug. 17, 2026. https://aws.amazon.com/blogs/machine-learning/build-openclaw-agents-that-transact-with-amazon-bedrock-agentcore-payments/
[23] PostHog, “@posthog/warlock,” GitHub repository (MIT). https://github.com/PostHog/warlock
[24] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Multi-Tenant Agent Security: The LLM Is Not Your Security Boundary,” Dotzlaw Consulting, August 25, 2026. /insights/ai-26-multi-tenant-agent-security/
[25] D. Nath and D. Swamy, “Build intelligent security for healthcare APIs with Amazon Bedrock,” AWS Machine Learning Blog, Aug. 20, 2026. https://aws.amazon.com/blogs/machine-learning/build-intelligent-security-for-healthcare-apis-with-amazon-bedrock/
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.