RAI Daily · Published edition

The permissions gap: what agents ask for and what they actually enforce

The control surface for AI agents moved again: a University of Washington survey of 21 agent-permission proposals plus five commercial agents finds that user-level permissions are largely unsolved, and that what an agent's interface asks you is often not what its runtime enforces.

TL;DR

  • **The control surface for AI agents moved again: a University of Washington survey of 21 agent-permission proposals plus five commercial agents finds that user-level permissions are largely unsolved, and that what an agent's interface asks you is often not what its runtime enforces.** T1
  • Top agentic red-team item: SkillSec-Eval tests 327 real-world reusable agent skills and shows vulnerabilities arise across the whole skill lifecycle (repository admission, retrieval, planner selection, evolution) not just at execution, where nearly all existing security work looks. T1
  • **Key regulatory item: the EU's Action Plan on Cybersecurity and AI (7 July) commits the Commission to evaluating AI models before they reach the EU market, an ENISA-built access blueprint, and a secure testing platform for critical sectors, weeks before the 2 August AI Act obligations bite.** T1

Thread of the day: Yesterday delegation became measurable; today three papers land on the thing delegation actually hands over: authorization. If the median agent session that ships an artifact now starts from a single human prompt, then the moment that matters is not the model's reasoning but the permission grant that precedes it, and the code the agent pulls in along the way. Three fresh arXiv papers (all submitted 15 July) converge on that layer from different angles: one finds the permissions literature has been solving for products rather than users; one shows the reusable-skill supply chain is vulnerable at stages nobody is testing; one argues penetration testing itself must be redefined, because an AI-enabled system can be broken without its infrastructure ever being compromised. The common claim is uncomfortable and worth sitting with: the agent can be behaving exactly as designed and still violate the objective you cared about, which means oversight has to attach to authority and provenance, not to the model.

What's new

The permissions gap: what agents ask for and what they actually enforce

Tier: T1 T1 (peer-reviewable preprint; abstract read and quoted directly) Pillar: Enterprise Governance (agentic lane ⚙: tool-use governance / authorization) What happened: Alexandra E. Michael and Franziska Roesner (University of Washington) published "How Agents Ask for Permission: User Permissions for AI Agents, from Interfaces to Enforcement" (arXiv:2607.13718, submitted 15 July 2026). They survey 21 proposals for agent permission systems and then compare them against five prominent commercial agents. Their framing of the risk is blunt: prompt injection and hallucination can cause agents to "leak private information to third parties," and as autonomous systems agents present "the more active danger of performing sensitive tasks, such as bank transactions, without the user's intent or authorization." Their core critique is that the field has optimised for the wrong unit. Much of the existing work is product-level, where "agentic system developers determine and apply the same security policies and permissions to all users", yet "different users have different needs and preferences, necessitating support for user-level permissions policies." The paper builds a taxonomy across three distinct stages that the literature tends to blur together: how systems specify permissions (at the interface and internally), how they derive internal policies from user input, and how they enforce those policies at run-time. It reports "multiple gaps where future work is needed." Why it matters in practice: This is the practical counterpart to the control research the library has been tracking all month, and it lands on the seam most enterprise agent deployments are quietly sitting on. The specify → derive → enforce split is the useful export: most vendor "agent permissions" stories are about the first stage, and the risk lives in the last two. A consent dialog that reads well tells you nothing about whether the runtime can actually stop the action, or whether the policy the system inferred from your click matches what you meant. If you are evaluating an agent platform, this paper hands you the interrogation: show me where the policy is enforced, not where it is displayed; show me how a user-specific rule survives translation into an internal policy. The finding that commercial agents diverge from the literature is the part to carry into procurement: the gap between the research consensus and what shipped is a gap your organisation is currently absorbing. Source: How Agents Ask for Permission: User Permissions for AI Agents, from Interfaces to Enforcement (arXiv:2607.13718)

Agent skills are a supply chain, and it's vulnerable where nobody is testing

Tier: T1 T1 (peer-reviewable preprint; abstract read and quoted directly) Pillar: Safety (agentic lane ⚙: agent evaluation / supply-chain risk) What happened: Sanket Badhe and Priyanka Tiwari published "Agent Skill Security: Threat Models, Attacks, Defenses, and Evaluation" (arXiv:2607.13987, submitted 15 July 2026), introducing SkillSec-Eval, described as "a lifecycle-aware framework for systematically evaluating the security of reusable agent skills." Their premise is that reusable skills "are becoming a fundamental building block of Large Language Model (LLM) agents, enabling capabilities to be packaged, shared, and reused across diverse applications", while "existing security research primarily focuses on prompt injection and runtime execution, leaving security risks throughout the broader skill lifecycle largely unexplored." The paper builds a threat taxonomy spanning five lifecycle stages, "repository admission, semantic retrieval, planner selection, execution, and skill evolution", and evaluates it empirically against a repository of 327 real-world skills. The headline result is a scoping claim rather than a single number: "vulnerabilities arise at multiple lifecycle stages beyond execution, highlighting the need for lifecycle-aware security analysis of reusable agent skills." Why it matters in practice: Every organisation now standing up an agent platform is, whether it has said so or not, taking a dependency on a package ecosystem, and this paper is the argument that we are securing it the way we secured software in about 2012, by scanning at run-time and trusting the registry. The five stages are the useful checklist because four of them happen before any code executes: what got admitted to the skill repository, what retrieval surfaced, what the planner chose, and what changed when a skill was updated underneath you. That last one, skill evolution, is the classic supply-chain shape: the artifact you audited is not necessarily the artifact you are running. Read this next to the permissions paper above and the picture sharpens: an agent with a well-scoped permission grant can still be compromised through a skill it was authorised to load. Note the honest limit. This is a framework-and-taxonomy contribution on one 327-skill repository, so treat it as a well-motivated research agenda and a threat model you can adopt today, not as a measured breach rate for your stack. Source: Agent Skill Security: Threat Models, Attacks, Defenses, and Evaluation (arXiv:2607.13987)

Penetration testing gets redefined: you can break an AI system without compromising anything

Tier: T1 T1 (peer-reviewable preprint; abstract read and quoted directly) Pillar: Safety (agentic lane ⚙: eval validity / red-team methodology) What happened: Mohammad Allahbakhsh, Mohammad Hassan Bahari and Moslem Attar-Raouf published "Rethinking Penetration Testing for AI-Enabled Systems: From Resource Compromise to Behavioral Objective Violation" (arXiv:2607.14006, submitted 15 July 2026). Their argument is that conventional pentesting, which asks whether an adversary can exploit "software, infrastructure, configurations, or operational controls", "remains necessary for AI-enabled systems, but it is no longer sufficient," because adversaries "may influence prompts, retrieved content, sensor inputs, training data, memory, tools, or human-AI interaction loops to alter system behavior without directly compromising the underlying infrastructure." They propose two definitions that do real work: an AI-enabled system is one "in which learned models materially influence behavior affecting operational outcomes," and AI-enabled penetration is "the feasible induction of AI-governed behavior that violates one or more operational objectives under an explicit threat model." The paper extends the discipline to cover "prompt injection, indirect prompt injection, data poisoning, sensor manipulation, retrieval poisoning, tool misuse, and agentic misalignment," and specifies a six-step workflow: identify operational objectives, map AI-governed behavior, analyse adversarial influence surfaces, define behavioral failure criteria, execute scenario-based tests, and report evidence "linking adversarial action to objective violation." A worked example uses an AI-enabled security operations centre assistant. Why it matters in practice: This one is short on empirics and long on framing, and the framing is the point, because it names a reporting problem that will land on someone's desk this year. If your pentest report has a clean bill of health, it may only be telling you that nobody broke the infrastructure. An agent that was manipulated through retrieved content into taking an authorised-but-wrong action produces no CVE, no privilege escalation, and no finding under the traditional method, which is exactly why "we passed our pen test" is becoming a weaker assurance claim for AI-enabled systems than it sounds. The practical move is to make the operational objective the unit of testing rather than the asset, and to require behavioral failure criteria to be written down before testing starts. Treat this as a methodology proposal rather than validated practice: it is definitional and workflow-level work, illustrated on a single running example, not an evaluated tool. But if you commission security testing for AI systems, the scope language in your next statement of work is where this belongs. Source: Rethinking Penetration Testing for AI-Enabled Systems (arXiv:2607.14006)

Brussels builds the machinery to test frontier models before they land

Tier: T1 T1 (European Commission publication; issuing-body page fetched and quote-verified today) Pillar: Policy What happened: The European Commission presented its Action Plan on Cybersecurity and Artificial Intelligence on 7 July 2026, structured around three objectives: "Promoting the safe and responsible use of advanced AI," "Reinforcing the EU's cybersecurity and resilience," and "Scaling up Europe's AI capabilities for cybersecurity." Its most consequential commitment is institutional: the Commission "will strengthen Europe's capacity to evaluate AI models before they are placed on the EU market, in line with the AI Act." Alongside that, it will work with ENISA to develop "a European Blueprint for secure access to advanced AI systems for cybersecurity purposes" and "establish a secure testing platform" for organisations in critical sectors, the Commission names "energy, transport, health, finance and public administration." The plan also leans on existing law rather than new rules, "promoting the implementation of existing EU cybersecurity legislation, including the NIS2 Directive and the Cyber Resilience Act," encourages the use of AI (including open-source models "where appropriate") for vulnerability detection, and launches an EU Grand Challenge on AI for cybersecurity. The Commission frames the threat symmetrically: AI "can also be exploited by malicious actors to automate attacks, identify weaknesses and carry out cyber operations at unprecedented speed and scale." Why it matters in practice: Strip the cyber framing and this is the EU answering the question the agentic-control literature keeps posing, who actually evaluates these systems, and with what capacity? A pre-market evaluation function for AI models is the regulator building its own version of the control evaluations the labs currently run on themselves, and it arrives weeks before the 2 August 2026 AI Act obligations start applying. The sector list is the line to read closely if you sell into the EU: energy, transport, health, finance and public administration are where a Commission-run testing platform will set the de-facto bar for what "safely test and deploy" means, and that bar tends to become the procurement question long before it becomes a legal one. Two honest caveats. First, this is an action plan, not a regulation. It commits the Commission to build capacity, and capacity announcements outrun delivery routinely. Second, the tell for whether it is real is staffing and budget for the evaluation function, not the document. Watch that, not the press release. Source: EU Action Plan on Cybersecurity and Artificial Intelligence (European Commission, 7 July 2026)

Worth watching

  • The 2 August 2026 AI Act applicability date is now inside the planning window, but the adopted Digital Omnibus moved the part that matters most. High-risk obligations are deferred to 2 December 2027 for standalone Annex III systems and 2 August 2028 for AI embedded in regulated products, which leaves Article 50's transparency duties as the substantive thing arriving next month. The rest of the EU lane (the Action Plan's evaluation capacity, the Article 6 high-risk classification guidance) now points at the later date. If you deploy agents into the EU, the open question is still whether agentic systems get classified high-risk by default, which would force reclassification of things already in production; you now have longer to answer it than the original calendar implied.
  • The Article 6 high-risk-classification consultation closes 23 July: one week out, and still the text most likely to determine where agentic systems land in the AI Act's risk tiers.
  • Fed/OCC/FDIC AI-specific RFI still unpublished: the standing US enterprise-supervision target, and the American counterpart to the EU/Singapore/IOSCO financial-supervisor moves the library has tracked all month.

Evidence: four Tier-1 sources, three arXiv preprints submitted 15 July 2026 (2607.13718, 2607.13987, 2607.14006), each read and quoted from its abstract, and the European Commission's Action Plan on Cybersecurity and Artificial Intelligence, fetched and quote-verified from the issuing body today. Zero Tier-2, Tier-3 and Tier-4 sources were used for factual claims. Two honest notes: the three preprints are new enough that none has cleared peer review, and each is scoped as taxonomy/framework work rather than a measured result, the briefing marks that limit in each block. The Commission's Action Plan is nine days old rather than fresh in the 24-hour window; it runs today because it had not previously been covered and its pre-market evaluation commitment bears directly on the agentic-control throughline.