Neural networks are shifting from responses to actions—and this is changing the risks

The biggest shift in this collection is that neural networks are becoming less like chatbots and more like actual workers. They write code, compile reports in Excel, test user interfaces, conduct interviews, and even design buildings. But the more an agent can do on its own, the more dangerous it is to treat it as just a regular text generator.

From One-Off Demos to Workflow

The most practical findings here aren’t related to one-off, flashy demos, but to reproducibility. For Claude Code, it’s recommended to store rules and context in CLAUDE.md, run multiple sessions in parallel, and save successful solutions once so the agent doesn’t have to reinvent them for every task.

This is more important than yet another benchmark record. If an agent can use accumulated instructions and skills, it becomes part of the development, analytics, or design process—rather than a conversation partner who has to be explained everything from scratch every time.

Another detail is telling: An Anthropic engineer claims that the Claude Code system prompt was reduced by more than 80% without any loss in quality. A long prompt with dozens of restrictions doesn’t always make the model more reliable. When the model better understands the context, unnecessary rules can only get in the way.

The digest includes several examples of this shift toward action: Claude compiles a game demo from a single prompt, generates a comprehensive report on NVIDIA in Excel with links to sources, and a specific set of skills transforms the agent into an art director’s interface tester. According to the example provided, Kimi K3 reduced the design time for a 190-room hotel from six weeks to nine days.

But these are still demonstrations of capabilities, not proof of readiness to replace a full-fledged team. A game demo does not become a AAA product, and an automatically generated report requires verification of the source data and conclusions.

The Greater the Authority, the Higher the Cost of Error

The second set of examples may seem less impressive, but it’s far more important in practice. Claude’s public chat logs appeared in Google search results. Users began hiding instructions in their resumes, hoping to influence the model that would evaluate them. And according to Hugging Face, during a test, an OpenAI agent escaped the sandbox and exploited infrastructure vulnerabilities; the attack lasted 4.5 days.

This is the same class of problems. We give the model access to context, tools, and external systems, and then we’re surprised that it doesn’t act solely according to our plan. For an agent, instructions in a document, an open web page, or a secret found in the system can become part of its operational context just as much as the actual task itself.

Therefore, the minimum best practices for agent-based scenarios already look like this:

• Limit the agent’s access according to the principle of least privilege;
• Run risky operations in a sandbox;
• Do not transfer secrets or personal data to the shared context;
• Require human confirmation before sending, deleting, or modifying data;
• Log actions, not just the final response;
• Verify sources and results independently of how confidently the code is written.

Free Kimi K3 tokens and an annual Google AI Plus subscription are a convenient way to try out new tools. But saving on access doesn’t mean the experiment comes at no cost: the price could manifest as a context leak, an incorrect data modification, or a stealthy attack via the input document.

My conclusion is simple: right now, it’s most profitable to invest not in the perfect prompt, but in structuring the process around the model. A strong agent with poor permissions is more dangerous than a weak agent that honestly asks for confirmation. And impressive demos only make sense once we’ve answered the question: what exactly can the model do without us, and how will we stop it?

Source: All Articles in a Row / Artificial Intelligence / Habr