Within permission, beyond intent: your agent logs just became evidence
When your agent acts within its permissions but beyond what you meant, who pays? Ship agents long enough and some version of that sentence stops being philosophy. This week it became a regulatory position, twice, in two
When your agent acts within its permissions but beyond what you meant, who pays?
Ship agents long enough and some version of that sentence stops being philosophy. This week it became a regulatory position, twice, in two hemispheres.
In the UK, four regulators said on October 30 that existing law already covers personal agents and the deployer is responsible the way an employer is. Today, November 6, ministers moved to add investigation powers to the Cyber Security and Resilience Bill for essential services and cloud providers running agents: incident reporting when safeguards fail, preservation of evidence, government-led reviews, and inspectors who may be able to enter premises and seize documents. Read that again as an engineer. Preservation of evidence. Your agent's logs, prompts and tool calls are now the kind of thing a regulator expects you to keep.
Australia ran the control experiment. Its Parliament's AI inquiry got 575 contributors, and nine financial institutions were asked the within-permission question directly: your customer's agent spends inside its granted permission but outside their intent, who carries the loss? Zero answers. Banks said the builders, one regulator said Treasury, another said the law as it stands, and the Productivity Commission said a future review. The case everyone will actually hit is the case nobody owns.
Here is the practitioner translation. If liability follows the deployer, and investigators can demand the evidence, then the deployer's defense is a record: what the agent was told, what it was allowed to touch, and what it actually did. Most stacks cannot produce that record today, and the failure starts somewhere embarrassingly small.
From the corpus, a real one: Groq prompt caching needs an exact prefix match. The pattern that works is static content first (system instructions, few-shot examples, tool definitions, schemas), dynamic content last (the user query, timestamps, session data), and you verify with usage.prompt_tokens_details.cached_tokens, hit rate cached over total. One stray timestamp near the top and the prefix drifts, nothing caches, and, more to the point, no two runs share the same instructions. That is a caching bug. It is also what an un-auditable agent looks like at the smallest possible scale.
The skill, with the full ordering rules and the limits (50% discount on cached input, roughly two hour idle expiry, gpt-oss models only for now): https://vectle.com/skills/skl_7rcxKR0ecsT04HxBKCxZeA
None of this needs a new statute to start. Freeze your prefixes. Log the granted scope next to the run. Keep the record longer than feels necessary. If a regulator, a bank or your own customer asks what the agent was allowed to do, "whatever the prompt said that day" is not an answer.
The wider library these field notes come from: https://vectle.com
Your turn: within permission, beyond intent, production incident. Who pays at your shop today, and could your logs prove what the agent was actually told?
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.