What permissions you're actually giving your company's AI agents

Why AI agents were allowed to act on their own

On 26 August 2026, Claude in Chrome reached general availability, and the real shift wasn't the extension itself, but the fact that AI agents can now carry out actions in the browser without approval for every step — until then, every click needed explicit user confirmation. This move isn't isolated: over the past year, the whole industry has shifted from “better models” to “agents that get the job done,” with ever-wider permissions and less step-by-step oversight, in production-grade applications with real memory and tools, not just conversations in a chat window.

For a company in Romania weighing up an AI agent — for marketing, for support, for internal processes — that raises a new question, one that “do we install it or not” no longer covers: how much freedom of action does that agent actually get, and who decides where it stops? The serious answer isn't “as much autonomy as possible,” but an explicit limit, set before the agent starts working, not discovered after the first incident.

“Agents Rule of Two”: the simple rule that prevents disasters

On 31 October 2025, Meta published a simple framework called the "Agents Rule of Two", designed specifically for companies that don't have a security team dedicated to AI agents. The rule identifies three risky capabilities an agent can have: processing unsafe content (coming from the internet, an email or an external document), access to sensitive data or systems, and the ability to change a state or communicate outward — sending an email, making a payment, publishing something. The rule is simple: an agent can have at most two of these three, without direct human oversight.

If an agent has all three at once — it reads unsafe content, has access to private data, and can act outward — without starting a new session between steps, it shouldn't be left to run fully autonomously. In that case, either limit one of the three capabilities, or introduce an explicit human approval step before the final action. It's a rule simple enough to check yourself, with no security consultant, for any agent you're considering putting into production.

What the "Rule of Two" means for your company's agent permissions

A concrete example: an agent that reads incoming emails and drafts replies it sends automatically has two of the three capabilities — it processes untrusted content (incoming emails can contain hidden instructions) and it acts on the outside world (it sends replies). If that agent doesn't also have access to other sensitive company systems, the combination stays, under the rule, within an acceptable zone for autonomy, with normal monitoring.

The situation changes radically if that same agent also gets access to the company's bank account or customer database — that adds the third capability, and the full combination calls for either removing one of the three or adding a human confirmation step before any irreversible action. The difference between a “useful agent” and a “security risk” isn't how sophisticated the underlying model is, but the exact combination of access you've given it, often without thinking about it explicitly.

Why it matters right now: injection remains unsolved

The reason this rule matters right now, not in two years, is that the industry was allowed to act autonomously before having a complete solution for prompt injection — the technique by which hidden text, placed in a web page or a document, hijacks an agent's instructions. The OWASP report on agentic applications shows that prompt injection maps onto six of the ten categories in the Agentic Top 10, and of fifty-three agentic projects tracked, twenty-eight are themselves coding tools — exactly the class of tool a software development company works with every day.

The practical takeaway isn't to avoid AI agents, but not to treat them like an ordinary chatbot: an agent that can browse the web unsupervised, or read documents from third parties, inherits exactly the risk the industry is still actively managing. Permission limits aren't pointless bureaucracy — they're the direct answer to a real, documented vulnerability, not a hypothetical one or one exaggerated by the press.

What the law requires: Article 50 of the AI Act, in brief

As of 2 August 2026, Article 50 of the European AI Act applies, introducing transparency obligations for any interactive system and for AI-generated synthetic content — in practice, a chatbot or an agent has to clearly tell the user that they're talking to an automated system, not a human. The grace period for watermarking content generated by systems placed on the market before 2 August runs until 2 December 2026, while the obligations for high-risk systems remain deferred to 2027-2028.

For a company that already uses AI-generated visual or video content in presentation materials or on its website — hero images, product visuals — that means a simple but necessary check: does that content meet the labeling obligation? It's not a dramatic process change, but it's the kind of detail that, if ignored, turns into a compliance problem that's easy to avoid if handled early, rather than discovered during an inspection.

The hidden risk: the skills you install for your agent

A separate but related part of the risk comes from the material agents are built from: skills — text instructions you install to extend what an agent can do. Snyk analysed almost four thousand public skills and found that over a third had at least one security issue, while a separate NVIDIA analysis found real vulnerabilities in roughly a quarter of its sample. One honesty note matters here: the Snyk report's title talks about "prompt injection" as a large share, but their own table shows injection accounts for only a small slice of the total — the rest are other, different categories of problems.

The practical takeaway is simple: a skill isn't a harmless text file — it inherits the agent's access to environment variables, API keys and sensitive folders. Before installing a skill package from an unfamiliar marketplace, it's worth running it through a dedicated scanner, the same way you'd scan any new code dependency before putting it into production — the security practices from software development apply here identically, this isn't a separate field.

A practical checklist before you let an AI agent act on its own

Before you let an AI agent act autonomously in your company, a few simple checks significantly reduce the risk, without requiring a dedicated security team or advanced technical knowledge — just the discipline to run through them every time you add a new capability to that agent or connect it to another tool. The list below is meant to take a few minutes to go through, not to be treated as a formal security audit.

This checklist doesn't replace a broader security discussion if the agent in question has access to financial operations or sensitive personal data about customers — in those cases, it's worth bringing in someone with specific experience in AI agent security, not just technical common sense. For most ordinary internal processes, though, these five checks cover the bulk of the real risk, at a time cost that's almost negligible compared with what they prevent.

• 01Explicitly list the three capabilities: private data, unsafe content, external action
• 02Check whether the agent has all three at once, with no new session in between
• 03Add a human approval step for any irreversible action
• 04Scan any skill or plugin before you put it into production
• 05Check whether any synthetic content generated meets the labelling obligation

Common mistakes when adopting AI agents at a company

The most common mistake is treating an AI agent like an ordinary productivity tool, with no explicit discussion of what access it gets — it gets installed, given credentials "so it works faster", and the question of permission limits never comes up at all. The second mistake is assuming that a "trusted" provider removes the need for your own checks — the two-out-of-three rule applies no matter who built the agent, because the risk comes from the combination of access, not from the quality of the model behind it.

The third mistake, the most costly in the long run, is putting off the conversation about permissions until after an incident — an email sent to the wrong person, an action carried out based on manipulated content, a data leak. The cost of setting boundaries from the start is close to zero; the cost of setting them after something has gone wrong almost always includes repairing lost trust, not just the affected technical system.

Sources and further reading.

• 01Meta AI Blog — Agents Rule of Two: A Practical Approach to AI Agent Security
• 02Help Net Security — OWASP prompt injection AI security failures
• 03Latham & Watkins — AI Act update: EU resolves to change rules and extend deadlines
• 04Snyk — ToxicSkills: malicious AI agent skills on ClawHub
• 05Help Net Security — SkillSpector: open-source agent skill security scanner
• 06Simon Willison — Prompt injection (ongoing coverage)

Frequently asked questions

The Niche Society TeamAI and software engineers from Bucharest · LinkedIn

published 2026-09-09