From prompts to privileges: Securing the age of AI agents

Moltbook, the world’s first social network for AI agents, launched in January 2026. Watching agents chat among themselves on a range of meandering topics, it felt like a glimpse of a future (dystopia?) where AI doesn’t just respond to our needs: it socializes, negotiates, and even founds religions, without human oversight.

But the novelty of Moltbook distracts us from its rather more mundane security risk; namely, when systems that speak also act, mistakes stop being local. In early reporting, security researchers said they could access Moltbook’s backend quickly and expose user data and a large volume of authentication tokens; enough, in theory, to impersonate accounts and manipulate activity. So, the security issue isn’t that agents exist. It’s that agents are often one integration away from data, endpoints, and business-critical workflows.

Prompt injection already showed how easily language interfaces can be manipulated. Agentic AI brings it up a notch because steering the output can steer the action: tickets opened, settings changed, scripts executed, access granted. According to the Open Worldwide Application Security Project (OWASP), most LLM apps process instructions and data together without a clean separation, which creates an opening for injected instructions to influence behavior.

What does this mean? Security leaders now need to treat natural language as a control plane and design proper guardrails.  

The shift to internalize: Prompts now lead to permissions

In chatbot contexts, prompt injection typically means making the model say the wrong thing, which can escalate into data exposure or policy bypass. In agentic workflows, the same technique can make the system do the wrong thing, because the model can use tools to act in the real environment; including cloud consoles, SaaS admin panels, ticketing systems, endpoint management, remote sessions, and internal scripts.

Indirect prompt injection is, well, less direct. OWASP describes it as a pattern where an LLM consumes external content (websites, files, documents) containing instructions that affect model behavior in unintended ways. Microsoft’s security team has said they commonly see indirect prompt injection in vulnerability reports.

Here’s one example of indirect prompt injection. Late last year, researchers found that Google’s LLM Gemini could be hacked with a malicious calendar invite. This meant that when people used the LLM to check in on their calendar, Gemini read the invite’s content as an instruction. This could then trigger actions in the real world, including manipulating smart home devices and extracting data. Google has thankfully addressed the issue since then.

But the riskiest part of agentic AI is rarely the model alone. Instead, risk is mainly in the integration layer, or the bridge between language and action. Every connector creates leverage. And if you didn’t design with security in mind, a single agent with broad permissions can move across systems faster than a person, repeat steps consistently (including bad ones), and generate a trail that’s difficult to interpret after the fact.

The best course of action, then, is to treat the agent interface like privileged access, because that’s what it often ends up being.  

4 risks of the agentic AI threat model

1) Instruction smuggling via indirect prompt injection

Agentic systems ingest content by design: webpages, emails, PDFs, chat histories, knowledge base articles, ticket threads, logs, and so on. That content often includes exactly what an agent needs to be helpful, including steps, commands, links, and other guidance. Unfortunately, it’s also an excellent hiding place for malicious instructions that read like routine operations.

This is why writing “better” system prompts isn't enough as a control. Because indirect prompt injection doesn’t always look like an attack. It can look like a troubleshooting note, a comment in a ticket, or, as we’ve seen, text in a seemingly innocuous calendar invite. For OWASP, the core problem is natural language instructions and data flow through the same channel, so the model can’t reliably separate “what to do” from “what to read.”

When a model can initiate actions, instruction smuggling becomes a way, among other things, to exfiltrate sensitive data, change state, create persistence, and even prevent detection.

What this means is that the true defense is workflow design (permissions, validation, gating, and so forth) and not clever wording.

2) Identity and accountability gaps

A lot of teams roll out agents using shared service accounts at first, because it’s the quickest way to get them working. But that convenience becomes an incident response problem the moment something goes wrong. If you can’t attribute actions, after all, you can’t investigate properly, and you can’t prove compliance.

The National Institute for Standards and Technology (NIST) has explicitly stated that agentic systems create new evaluation and security challenges, including “agent hijacking” scenarios where agents get steered away from intended objectives.

But even without a full hijack, basic questions matter in day-to-day operations. Questions like: Which agent initiated the action? Who authorized it? What inputs did the agent rely on? What actions did it attempt, and what worked?

If you don’t have clear answers to these questions, then something has gone wrong with your process.

So, the goal is clear, if not always easy: distinct identities per agent/workflow, rather than shared credentials; clear mapping between an actual person and the agent’s actions, along with detailed logs.

3) Privilege creep and secret sprawl

Agentic tools tend to start small. Then reality arrives and, with it, a growing list of things the agent “needs” access to. Permissions grow, and temporary exceptions turn into the status quo.

All the while, tokens and keys spread. They show up in logs, test environments, demos, misconfigured storage, or front-end code where they never belonged. In the Moltbook reporting, researchers described exposed tokens and misconfigurations that increased the impact of classic failures, made only more serious by the system’s scale and connectivity.

So, privilege creep is not unique to AI, but agentic AI accelerates it.

Why? Well for one thing, agents made it incredibly easy to add integrations. On top of that, teams can underestimate the risks of wide access. This means that the blast radius grows quietly until a single compromised interaction can reverberate across systems.

So, if you want one operational rule, it’s this: treat every new agent tool connection like onboarding a new privileged admin. Because that’s what it becomes in practice.

4) Workflow and logic-layer manipulation

A lot of people picture AI security as a battle over secrets. Something like, can the attacker trick the model into revealing something? And that happens, but the bigger operational risk often looks different. Attackers aim at the workflow.

They steer decisions, reorder steps, suppress signals, or trigger actions at the wrong time. Some of the most damaging failures look like normal work: a “standard fix” gets pushed too broadly; alert triage deprioritizes the signals that matter most, or a ticket resolution effectively buries the evidence needed to investigate.

And this is why model alignment doesn’t solve the whole problem. The vulnerability sits in the logic of the system: what counts as an acceptable request, what sources are trusted, what checks exist before execution, and what the agent is allowed to do when confidence is low.

What secure agentic AI looks like in practice

1) Build secure workflows, not perfect prompts

Prompts shape behavior. They do not enforce security. Use them to improve usability and reduce accidental misuse but always assume adversarial inputs will still reach the system.

Some design patterns that work:

• Constrain the action space. Define a small set of approved actions for a specific workflow and deny everything else by default.
• Separate “read” from “act.” Let the agent summarize and propose actions but require additional checks before execution.
• Add deterministic validation. Use schema checks, allowlists, policy rules, and sanity constraints before any tool-call that changes state.
• Treat external content as untrusted. If the agent reads the web or opens documents, assume that content can contain malicious instructions.

2) Least privilege, with time bounds

Least privilege needs to be the operating principle of working with agentic AI. But this requires discipline, because we’re understandably tempted to grant access for convenience’s sake.

Some practices that reduce vulnerabilities:

• Scope access by task and domain. Let’s say an agent summarizes endpoint health. They shouldn't need to be able to change endpoint configurations.
• Use short-lived credentials. Prefer just-in-time access with expiration instead of long-lived keys.
• Make revocation routine. You need a clean, frequent path to review what an agent can touch. Get rid of what it shouldn’t.
• Separate environments. Keep dev/test/prod boundaries hard, so experimentation doesn’t spill into production.  

This is also where teams should decide which actions an agent should never do on its own. Some organizations will let an agent open tickets. Much fewer should let an agent grant access without approvals.

3) Human-in-the-loop for high-impact actions

Human oversight doesn’t mean that someone clicks “approve” on everything. This approach collapses quickly and somewhat defeats the purpose of automation. Instead, reserve approvals for actions that are irreversible or high impact, including access changes, mass deployments, or destructive cleanups.

At the same time, you should provide constant feedback for the agent, so that it can improve. This is invaluable. After all, as my colleague Sebastian Schrötel points out in another recent article about AI agents: “You shouldn't simply activate the system and leave it unattended. Instead, you need to review its work like you would a junior employee.” 

4) Monitoring and remediation at operational speed

Agentic systems can operate at machine speed. Detection often doesn’t. That mismatch is where small failures become incidents.

The trick is to treat agent actions like privileged user activity:

• Monitor unusual targets, timing, volume, and sequences
• Correlate across systems (ticketing + endpoint changes + identity events)
• Add stop conditions when risk rises mid-workflow

Then make response real:

• Contain quickly (pause the agent, revoke tokens, isolate affected endpoints)
• Roll back safely (configuration restoration, policy revert)
• Rotate credentials when exposure is suspected
• Capture learnings as workflow rules, not tribal knowledge