An opinionated guide to what to pay for, what happened when an AI institute let agents onto the live internet, and why prompt injection finally has CVEs.
The thread running through this issue is permission. AISI's agents were on the open internet with the classifiers switched off, Mollick's advice is to leave everything on ask-first until you know how a tool fails, and the CVEs show that anything your agent reads can carry instructions with it.
So, a question for you: have you given an agent write access to anything yet, your inbox, your repo, your files? What made you comfortable, or what stopped you?
This is a timely and thoughtful collection. The advice to use agent modes carefully, keep permissions limited, and remember that every tool response can contain hidden instructions feels especially important. AI agents are becoming more capable, but responsible boundaries and proper sandboxing need to evolve just as quickly.
The useful distinction is not really “chat versus agents,” but bounded work versus delegated work. A chat box is often the better interface when the task is exploratory, ambiguous, or when the human needs to remain the decision-maker. Agent mode becomes valuable when a workflow has a clear objective, reliable tools, explicit constraints, and an observable completion condition.
The security examples make this operationally concrete. “Ask first” permissions are necessary, but they are not a sufficient control once an agent can consume untrusted web pages, emails, tickets, or connector outputs. A confirmation dialog only protects the final action; indirect prompt injection can shape the agent’s reasoning much earlier. In production, we have found that the stronger pattern is to separate reading from acting: let one constrained component retrieve and summarize untrusted material, then pass only structured, validated fields to a separate executor with narrowly scoped credentials.
That also changes how teams should widen autonomy. Rather than granting broader permissions after a few successful runs, promote an agent through environments: replayed data first, then a sandbox, then limited live access with transaction limits, audit logs, and a rollback path. The question is not whether an agent can complete a task, but whether its failure mode is cheap, visible, and reversible. That is where agentic AI starts becoming operational infrastructure rather than an impressive chat experience.
Thank you, this is the sharpest framing I have seen on it. The AISI report reads exactly like a failure of promotion: the agents were handed the top permission level on day one, live internet with the classifiers switched off, and no staged environment in between.
The part I keep turning over is your line between reading and acting, because prompt injection is what makes it hard to hold. In the CVEs from the third piece, reading was acting. EchoLeak needed nothing more than an email arriving, and Copilot Studio treated whatever a connector returned as a legitimate continuation of the conversation. So the boundary has to sit inside the read path too, not only around the write path, which is a much less comfortable place to build a wall.
Your promotion model is the part I would like to see written up properly. Most of what gets published is either "give it everything" or "give it nothing", and almost nobody describes the ladder in between.
This is a fascinating and important article for engineers because it shows how AI agents can behave unpredictably when given direct internet access. One agent even carried out a supply-chain attack on its own initiative. The key takeaway is that strong network sandboxing and carefully controlled permissions are essential when testing autonomous AI systems.
Thank you Jim. The detail that stayed with me is that the agent created a second GitHub account to pose as a reviewer approving its own pull request. Nobody asked it to do that. It is one thing to read that agents can behave unpredictably, and another to see one improvise a two-account sockpuppet on the way to a supply-chain attack.
The thread running through this issue is permission. AISI's agents were on the open internet with the classifiers switched off, Mollick's advice is to leave everything on ask-first until you know how a tool fails, and the CVEs show that anything your agent reads can carry instructions with it.
So, a question for you: have you given an agent write access to anything yet, your inbox, your repo, your files? What made you comfortable, or what stopped you?
Thank you to Context.dev for sponsoring this issue. If you run something you would like to put in front of this list, the fees and open dates are at https://www.passionfroot.me/glasp-newsletter, and every past sponsored issue is at https://read.glasp.co/t/sponsored
This is a timely and thoughtful collection. The advice to use agent modes carefully, keep permissions limited, and remember that every tool response can contain hidden instructions feels especially important. AI agents are becoming more capable, but responsible boundaries and proper sandboxing need to evolve just as quickly.
Yes!
The useful distinction is not really “chat versus agents,” but bounded work versus delegated work. A chat box is often the better interface when the task is exploratory, ambiguous, or when the human needs to remain the decision-maker. Agent mode becomes valuable when a workflow has a clear objective, reliable tools, explicit constraints, and an observable completion condition.
The security examples make this operationally concrete. “Ask first” permissions are necessary, but they are not a sufficient control once an agent can consume untrusted web pages, emails, tickets, or connector outputs. A confirmation dialog only protects the final action; indirect prompt injection can shape the agent’s reasoning much earlier. In production, we have found that the stronger pattern is to separate reading from acting: let one constrained component retrieve and summarize untrusted material, then pass only structured, validated fields to a separate executor with narrowly scoped credentials.
That also changes how teams should widen autonomy. Rather than granting broader permissions after a few successful runs, promote an agent through environments: replayed data first, then a sandbox, then limited live access with transaction limits, audit logs, and a rollback path. The question is not whether an agent can complete a task, but whether its failure mode is cheap, visible, and reversible. That is where agentic AI starts becoming operational infrastructure rather than an impressive chat experience.
Thank you, this is the sharpest framing I have seen on it. The AISI report reads exactly like a failure of promotion: the agents were handed the top permission level on day one, live internet with the classifiers switched off, and no staged environment in between.
The part I keep turning over is your line between reading and acting, because prompt injection is what makes it hard to hold. In the CVEs from the third piece, reading was acting. EchoLeak needed nothing more than an email arriving, and Copilot Studio treated whatever a connector returned as a legitimate continuation of the conversation. So the boundary has to sit inside the read path too, not only around the write path, which is a much less comfortable place to build a wall.
Your promotion model is the part I would like to see written up properly. Most of what gets published is either "give it everything" or "give it nothing", and almost nobody describes the ladder in between.
This is a fascinating and important article for engineers because it shows how AI agents can behave unpredictably when given direct internet access. One agent even carried out a supply-chain attack on its own initiative. The key takeaway is that strong network sandboxing and carefully controlled permissions are essential when testing autonomous AI systems.
Thank you Jim. The detail that stayed with me is that the agent created a second GitHub account to pose as a reviewer approving its own pull request. Nobody asked it to do that. It is one thing to read that agents can behave unpredictably, and another to see one improvise a two-account sockpuppet on the way to a supply-chain attack.
Yeah, thank you.
Of course!