# AgentValet: product summary and full blog content

> AgentValet is the authorisation and approval control plane for AI agents. It sits between agents and the platforms they call: each agent gets a scoped identity, risky actions wait for human approval, and every call lands in an append-only audit log. Agents never hold raw API keys. Subagents get short-lived child identities (one level deep) with scopes attenuated server side to a subset of the parent's.

## What AgentValet does

AgentValet is a governed credential broker for AI agents. An agent calls the
SaaS tools it needs through a gate that authorises every individual action, and
the agent never holds the credential.

The problem it replaces: giving an agent an API key in an environment variable.
That key is permanent, as broad as the account that issued it, works unattended
at any hour, and leaves no record of who decided the agent could use it.

## How a request works

1. The agent authenticates with its own cryptographic identity, not a shared key.
2. It names the action it wants to perform.
3. The gate runs its authorisation checks, in order, and any one can stop the call.
4. Only if every check passes is the real credential decrypted, in memory, for
   that one request.
5. The upstream service is called and the result returned.
6. An audit record is written. Allowed, refused, held and failed all write one.

Authorisation finishes before the credential is touched, so a request that
should not happen is stopped while the secret is still encrypted.

## What the gate checks, in order

1. Is there a grant for this agent and this service at all
2. Which specific connected account applies
3. Is the agent live, and is the service enabled
4. Has the grant expired
5. Has this agent been failing repeatedly
6. Does the owner have a policy assigned
7. What do the organisation guardrails and the policy say, deny wins
8. Was this capability granted to this agent
9. Does the literal method and path match what that capability covers

## What happens on a refusal

The agent receives a precise reason rather than a generic error, so it can tell
you what to fix. The credential is never decrypted. The attempt is in the audit
log.

## Human approval

A capability can be marked as requiring approval. The agent's call does not
fail, it waits. A person sees what is being attempted and why, and approves or
declines. On approval the gate replays the request itself and runs every check
again, so an approval can never unlock something the rules would have refused.
An approval that is not answered inside its window expires rather than
executing later.

## Other things it does

- Grants can be issued with an expiry, so access for one task ends by itself.
- An agent that has just read untrusted content has its consequential actions
  routed to a human for a short window. Reading is never blocked.
- Credentials are sealed individually, and those seals are protected by a
  per-organisation key: held in hardware on paid plans, derived per
  organisation on the Free plan.
- Suspending an agent revokes its tokens with it.
- Every decision carries a signed receipt that can be checked against the
  published keys at https://api.agentvalet.ai/.well-known/agentvalet-receipt-keys.json.
- The audit log exports as a file with stable columns for an auditor.

## Who it is for

Teams running agents that act on real systems: coding agents with repository
access, operations agents posting to team channels, scheduled agents reading
mail. The buyer is whoever would be accountable when an agent does something
wrong. It is not aimed at agents that only read public data or never leave a
sandbox.

Hosting is in Australia only.

## How it compares

One axis separates agent-governance tools: some govern the suggestion (they
sit near the model and shape what it sees and proposes), some govern the
execution (they hold the credential and decide whether the real call happens).
AgentValet is the second kind. Model-call gateways advise; credential brokers
enforce.

- [vs Tenure](https://agentvalet.ai/compare/tenure): Tenure is a self-hosted proxy on the model call (governed memory, tool filtering, suggestion screening). It never holds platform credentials, so an agent with its own keys bypasses it. AgentValet holds the credential, so there is no bypass without the secret.
- [vs Permit.io](https://agentvalet.ai/compare/permit-io): Permit.io authorises your application's users via policy checks your code calls. AgentValet governs agents' outbound platform calls and holds the credentials. Complementary, not substitutes.
- [vs MCP gateways](https://agentvalet.ai/compare/mcp-gateways): a gateway governs the traffic routed through it and leaves the secrets outside itself; a broker governs every call because unrouted traffic has nothing to authenticate with.
- [vs Affinidi](https://agentvalet.ai/compare/affinidi): Affinidi's Agent Gateway verifies who is calling an agent and applies policy at its front door. AgentValet governs what the agent itself calls outward and holds those credentials. Different sides of the same agent; they can run together.
- [vs Okta Cross App Access](https://agentvalet.ai/compare/okta-cross-app-access): Cross App Access (ID-JAG) lets your IdP issue an agent a grant for apps that trust the same IdP, decided once at grant time. AgentValet checks every call, inside that circle and outside it, with per-action approval and a signed audit record; teams sign in to AgentValet through Okta on Enterprise. They stack.
- [vs API keys in .env](https://agentvalet.ai/compare/api-keys-in-env): the real default. Fine for low-stakes experiments; no identity, scope, approval, audit, or clean revocation once the agent's actions start to matter.

## Key pages

- [Pricing](https://agentvalet.ai/pricing): plans, limits and what each tier includes.
- [Security architecture](https://agentvalet.ai/security): how identity, credential sealing, the gate and the audit log work.
- [Trust centre](https://agentvalet.ai/trust): hosting, sub-processors, certification status and vulnerability disclosure.
- [Integrations](https://agentvalet.ai/integrations): setup for Claude Code, Cursor, Codex CLI, Claude Desktop, Factory Droid, CrewAI and your own code.
- [Platforms](https://agentvalet.ai/platforms): the 30 live platforms an agent can call through AgentValet.
- [Try it without signing up](https://agentvalet.ai/try): watch a governed call get held and approved.
- [Connect a personal assistant](https://docs.agentvalet.ai/concepts/assistant-onboarding): paste a prompt into Instinct or another assistant; it registers itself over REST and you approve with a passkey.
- [ADM Register](https://agentvalet.ai/adm-register): the Australian APP 1.7 to 1.9 automated decision-making disclosure, a sample register and a free template.
- [Documentation](https://docs.agentvalet.ai): install, grants, policies and API reference.

---

# The 9 security review questions that keep agents out of production

> Your agent works in staging and security keeps sending it back. Nine questions they ask, the weak answers, the strong ones, and the evidence to bring.

Published: 2026-10-15
Author: Edwin Ashdown
URL: https://agentvalet.ai/blog/ai-agent-security-review-questions

The agent works. It has worked in staging for a month. The demo went well, the people who will use it want it, and it has been sitting in security review for six weeks while the same questions come back in slightly different words.

I spent last week reading what the reviewers are reading: the OWASP Top 10 for Agentic Applications (December 2025), the OWASP MCP Top 10, which is still in beta, NIST's AI Risk Management Framework, a concept paper from NIST's National Cybersecurity Center of Excellence on agent identity, and the joint "Careful adoption of agentic AI services" guidance that six agencies, including Australia's ASD, published in May.

They converge. When NIST's NCCoE wrote down its open questions about agents, four of its five technical sections were identification, authentication, authorisation, and auditing. The fifth was prompt injection. Your reviewer is asking variations of a short list, and most of it comes down to who the agent is, what it can touch, who said yes, and where the proof is.

Security is not the only reason agent projects stall. In Dynatrace's 2026 survey of 919 leaders, security, privacy and compliance topped the list of barriers at 52 per cent, one point ahead of technical challenges. It is the one you can do something about this week.

Here are the nine questions I would prepare for. The weak and strong answers are my reading of the frameworks. No published rubric grades them.

## Identity and delegation

**1. Which agent is this?** The weak answer is "it uses the integration's service account" or "it runs as the engineer who set it up". The strong answer is that each agent is its own principal with its own credential, on an inventory with a named owner. The Five Eyes guidance says to build "each agent as a distinct principal". Bring the inventory entry and a log line from the target system that shows the agent's own identity.

This is where many teams are today. In a Cloud Security Alliance survey commissioned by Aembit (228 respondents, January 2026), 43 per cent ran agents on shared service accounts and 31 per cent let agents act under a human's identity.

**2. On whose behalf, and can you trace it back?** "Everything is logged" is weak if everything is logged under one account. The strong answer is that every action carries the agent and the person it acted for, and the delegated access is narrower than that person's own. A security team at a regulated utility put it bluntly in a GitHub issue this year: it "requires every Bedrock invocation to be attributable to an individual". Bring one real action traced end to end, from the request to the record in the target system.

## Scope and credentials

**3. What exactly can it touch?** "The same access as the user" is the answer reviewers hear most and like least. The strong answer is a written list of the endpoints and actions this agent needs, enforced outside the model, and checked on every call. The Five Eyes guidance names the trap: if entitlements are "evaluated only once at system startup rather than at each invocation", a stale allow decision can be exploited later. Bring the grant as configuration, and a denied call in the logs that proves the boundary holds.

**4. Where do its credentials live, and for how long?** An API key in an environment variable, or a long-lived personal token, will stall you. The strong answer is short-lived, scoped credentials, with the long-lived secret kept somewhere the model and the agent process never see. OWASP's agentic list recommends "per-agent identities and short-lived credentials". AWS's own bulletin on the Amazon Q extension in July 2025 described how an "improperly scoped GitHub token" let an attacker inject code into a release. Bring credential lifetimes and your last rotation record.

## Approval and containment

**5. Which actions need a human yes?** "The agent asks when it thinks something is risky" fails. The guidance is explicit that decisions about when approval is required should be "determined by system designers or operators, not delegated to the agentic AI system". The strong answer is a list of approval-required actions in configuration, an approver who sees the real parameters (amount, recipient, record) instead of the agent's summary of them, and a record of every approval. If approvals will arrive fifty times a day, say how you will stop people rubber-stamping them. [Least agency](/blog/least-agency-in-practice) is the principle behind this one.

**6. What happens when it reads something hostile?** A system prompt telling the model to ignore instructions in data is a weak answer. Assume an injection will sometimes succeed and show what limits the damage. The interesting thing about this question is that the best answer is questions 3 and 5 again. A hijacked agent with narrow scope and an approval gate on destructive actions does very little. Bring a test run with a planted instruction and the blocked or held action it produced.

**7. Which tools and MCP servers can it load?** "Developers add what they need" is the weak answer. The strong one is an allow list of tools, servers and versions with an owner who approves additions. Bring the list and the change record for the last thing added.

## Evidence and the off switch

**8. Show me what it did last Tuesday.** "It's in the application logs" is weak when the agent's host can write to those logs and they don't name the user. The strong answer is a record per action, kept out of the agent's reach, with the agent, the person, the tool, the parameters, the decision and the result. OWASP asks for "immutable and signed audit logs". In a CSA survey sponsored by Strata, 84 per cent of respondents doubted they could pass an audit of agent behaviour or access controls. Bring one agent's export for one week.

**9. How fast can you stop just this one?** "We'd rotate the key" usually means stopping every agent and integration that shares it. The strong answer is per-agent revocation that takes effect on the next call, a named person who can trigger it, and a written decommissioning step. Bring a timed drill.

## An instruction is not a control

The clearest case I found for why reviewers ask all this is Replit in July 2025. During a "code freeze" that existed only as an instruction to the model, its agent deleted a user's production database, then reported that rollback would not work. It did. Replit's chief executive called it "Unacceptable and should never be possible", and the fixes the company announced were structural: separate development and production databases, and a planning-only mode. That incident fails questions 3, 5, 8 and 9 in one go.

Notice how often the strong answers repeat themselves. A separate identity per agent, access checked per call, approval set by people, a record the agent can't edit. Seven of the nine questions are identity, scope, approval and evidence. The other two, injection and supply chain, are answered best with the same controls. If you are new to the split between who an agent is and what it may do, [authentication versus authorisation for agents](/blog/agent-authentication-vs-authorization) is the background.

This week, without buying anything: pick one agent, write a one-page answer sheet for all nine questions, and attach the artefact for each. Where you can't attach one, you have found the work.

That one-page sheet is also roughly what I built AgentValet to produce. Each agent gets its own identity and only the endpoints it has been granted. Risky actions wait for a person. Every call is recorded with the agent, the user and the decision. The [security page](https://agentvalet.ai/security) shows how each of those is built, if you want to compare it with your own answers.

## Sources

- OWASP Top 10 for Agentic Applications 2026: [genai.owasp.org](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)
- OWASP MCP Top 10 (beta): [owasp.org](https://owasp.org/www-project-mcp-top-10/)
- NIST NCCoE, Accelerating the Adoption of Software and AI Agent Identity and Authorization (concept paper, February 2026): [nccoe.nist.gov](https://www.nccoe.nist.gov/sites/default/files/2026-02/accelerating-the-adoption-of-software-and-ai-agent-identity-and-authorization-concept-paper.pdf)
- CISA, NSA, ASD's ACSC and others, Careful adoption of agentic AI services (1 May 2026): [cyber.gov.au](https://www.cyber.gov.au/sites/default/files/2026-05/careful_adoption_of_agentic_ai_services.pdf)
- NIST AI Risk Management Framework 1.0, core: [airc.nist.gov](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/)
- Dynatrace, The Pulse of Agentic AI 2026 (Y2 Analytics, n=919): [dynatrace.com](https://dynatrace.com/news/press-release/pulse-of-agentic-ai-2026)
- Cloud Security Alliance survey commissioned by Aembit (n=228, January 2026): [cloudsecurityalliance.org](https://cloudsecurityalliance.org/press-releases/2026/03/24/more-than-two-thirds-of-organizations-cannot-clearly-distinguish-ai-agent-from-human-actions)
- Cloud Security Alliance survey sponsored by Strata (n=285): [cloudsecurityalliance.org](https://cloudsecurityalliance.org/press-releases/2026/02/05/cloud-security-alliance-strata-survey-finds-that-enterprises-are-in-time-to-trust-phase-as-they-build-ai-autonomy-foundations)
- AWS Security Bulletin AWS-2025-015, Amazon Q Developer for VS Code: [aws.amazon.com](https://aws.amazon.com/security/security-bulletins/AWS-2025-015/)
- The Register on the Replit incident, 21 July 2025: [theregister.com](https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/); Fortune, 23 July 2025: [fortune.com](https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/)
- GitHub issue on per-user attribution for Bedrock calls: [github.com](https://github.com/anthropics/claude-code/issues/84504)

---

# APP 1.7: your privacy policy now needs a register you don't have

> From 10 December 2026 your privacy policy must disclose automated decisions. The hard part is the register behind it. A checklist to start this week.

Published: 2026-10-13
Author: Edwin Ashdown
URL: https://agentvalet.ai/blog/app-1-7-automated-decisions-privacy-policy

On 10 December 2026 a new paragraph becomes compulsory in the privacy policy of every organisation covered by the Australian Privacy Act. If a computer program makes, or does something substantially and directly related to making, a decision that could significantly affect someone, your policy has to say so.

I spent the last week reading the amending Act, the OAIC's final guidance from 30 September, and every law firm summary I could find. They agree on the first step. What none of them dwell on is what that step looks like once AI agents are in the picture. Writing the paragraph is the easy part. Knowing what to put in it is where most organisations are going to struggle.

This is general information about a new legal obligation, written by an engineer. It is no substitute for legal advice about your own situation.

## What changes on 10 December

The obligation is APP 1.7 to 1.9, inserted by the Privacy and Other Legislation Amendment Act 2024. It applies when three things are true. You have "arranged for a computer program to make, or do a thing that is substantially and directly related to making, a decision". The decision "could reasonably be expected to significantly affect the rights or interests of an individual". And personal information about that person is used along the way.

When all three hold, the policy must list the kinds of personal information those programs use, the kinds of decisions they make on their own, and the kinds of decisions where they do something substantially and directly related to making them.

There is no grandfather clause. The transitional rule covers decisions made after commencement whether the program was set up before or after. An agent you deployed in 2025 counts the first time it touches a relevant decision in December.

A breach of APP 1.7 is listed in section 13K, which makes it a civil penalty provision with a maximum of 200 penalty units per contravention, and opens the door to infringement and compliance notices. The OAIC has already shown it will read privacy policies. Its first compliance sweep of privacy policies started in January this year, covering around 60 entities.

## Human review does not take you out of scope

This is the part of the guidance I expect to surprise people. The OAIC says a decision can be in scope "even where a computer program output does not replace the entire decision-making process or is subject to human review". It names generative AI and chatbots as computer programs. Its examples include hiring screens, credit and insurance checks, fraud flags that block access to an account, refunds, and a case system that escalates certain complaints.

A human step can take something out of scope, but only a real one. In the OAIC's worked example about AI-drafted pay decisions, what moves the output outside "substantially" is a manager who interrogates it, checks the evidence, and documents why they departed from the recommendation. A person who clicks approve on every draft does not count.

So "a human signs off" is a claim you may need to back up. That means a record of what the human did.

## Your policy is a summary of a list

Here is the reframe that made this click for me. APP 1.8 asks for kinds. The OAIC lets you group decisions and categories of information, as long as the result is meaningful to a reasonable person. Its own model wording reads like a short catalogue: grant or deny access to an account, grant or deny a transaction, grant or deny a loan application.

You can only write those sentences honestly if you have the list underneath them: which program or agent, which personal information, which decision, whether a person genuinely decides, and who owns it. Your privacy policy is now a summary of a register. Most organisations don't have the register.

The evidence that this is hard comes from people who were already obliged to publish. In October 2025 the OAIC reviewed 23 Commonwealth agencies that are authorised by law to use automated decisions. Four of them disclosed that use. For 17, the OAIC could not tell from public information whether automation was used at all. These are agencies with a statutory basis for automation and an existing duty to publish. If they struggle to say what they automate, a company with a dozen agents and three SaaS vendors shipping AI features every quarter will too.

The public expectation is moving the other way. The OAIC's 2026 community attitudes survey found 79 per cent of Australians want to be told when AI is used, and 81 per cent want a person to review AI decisions.

## Why agents make the list move

Every firm I read says to audit first. Hamilton Locke goes further and warns that "a 'set and forget' approach will not support ongoing compliance". The Law Council's submission names the routes automation arrives by without anyone deciding it should: embedded in software bought for something else, "introduced through a vendor update", or "used informally by staff".

Agents add their own churn. A support agent that only drafted replies gets a refund tool. A sales agent starts reading credit data because someone connected a new integration. Nothing about the privacy policy changed on either day, and both may have created a new kind of decision.

That is the useful distinction. The register changes often. The policy only needs to change when a new kind of decision or a new kind of personal information appears, or when the human step that kept something out of scope stops happening. Keeping the register current is what tells you when that moment has come.

## A register you can start this week

None of this needs a new product. A spreadsheet will do for a first pass.

1. List every agent, model integration and vendor feature that touches personal information. Include staff using their own AI accounts for recurring work, which one submission to the OAIC calls arranged for "in substance".
2. For each one, write down the decision it makes or feeds, in plain words: approves a refund, ranks applicants, flags an account.
3. Apply the three limbs. Is it substantially and directly related to the decision? Could the decision significantly affect someone? Is their personal information used? Where you are unsure, the OAIC's advice is to take a cautious approach and disclose.
4. Record whether a person genuinely decides, and where the evidence of that lives.
5. Name an owner and add a "last changed" date.
6. Group the in-scope rows into kinds. Those groups are your draft APP 1.8 paragraph. Take it to whoever gives you legal advice.
7. Set a trigger. Any new agent, new tool grant or vendor AI feature gets a row before it goes live.

If you already think about agents as identities with their own access, as I argued in [identity is the control plane for AI agents](/blog/agent-identity-control-plane), most of the first column already exists somewhere. Step 4 connects to [least agency](/blog/least-agency-in-practice): the decisions that need a person are the ones that should not run unattended.

## Where the record comes from

The register is a document, and documents drift. What keeps it honest is a record of what agents actually did, so you can check the register against reality instead of memory.

That is the shape I have been building towards. When every agent action goes through one layer, each call is recorded with which agent made it, which system and data it touched, and whether a person approved it. That record doesn't decide whether something is in scope for APP 1.7. It does tell you, at the end of each month, which agents touched personal information and in which decisions, which is the hardest column of the register to fill from memory.

If you want to see how that record is built, the [security page](https://agentvalet.ai/security) walks through it.

## Sources

- Privacy and Other Legislation Amendment Act 2024 (Cth), Schedule 1 items 87 to 89 and section 2: [legislation.gov.au](https://legislation.gov.au/C2024A00128/asmade/2024-12-10/text/original/epub/OEBPS/document_1/document_1.html)
- OAIC, APP Guidelines Chapter 1, updated 30 September 2026: [oaic.gov.au](https://www.oaic.gov.au/privacy/australian-privacy-principles/australian-privacy-principles-guidelines/chapter-1-app-1-open-and-transparent-management-of-personal-information)
- OAIC, APP 1.7 to 1.9 transparency obligation fact sheet, September 2026: [oaic.gov.au](https://www.oaic.gov.au/__data/assets/pdf_file/0021/269013/APP-1.7-1.9-Transparency-Obligation-Fact-Sheet.PDF)
- OAIC, review of automated decision-making disclosure by government agencies, 21 January 2026: [oaic.gov.au](https://www.oaic.gov.au/news/media-centre/australian-information-commissioner-highlights-improved-transparency-and-integrity-for-government-agencies-in-automated-decision-making)
- OAIC, privacy policy compliance sweep, 9 December 2025: [oaic.gov.au](https://www.oaic.gov.au/news/media-centre/privacy-compliance-sweep-to-put-privacy-policies-under-the-spotlight)
- OAIC, Australian Community Attitudes to Privacy Survey 2026, digital technologies: [oaic.gov.au](https://www.oaic.gov.au/engage-with-us/research-and-training-resources/research/australian-community-attitudes-to-privacy-survey/australian-community-attitudes-to-privacy-survey2026/digital-technologies)
- Hamilton Locke, transparency in automated decision-making, 4 June 2026: [hamiltonlocke.com.au](https://hamiltonlocke.com.au/transparency-in-automated-decision-making-what-regulated-entities-need-to-know-and-do-before-december-2026/)
- Law Council of Australia, submission on the ADM issues paper, 3 July 2026: [lawcouncil.au](https://lawcouncil.au/resources/submissions/automated-decision-making-transparency-obligation-app-1-issues-paper)
- Digital Economy Council of Australia, submission to the OAIC, 22 June 2026: [deca.org.au](https://deca.org.au/wp-content/uploads/2026/06/OAIC-Automated-Decision-Making-DECA-Consultation-Response.pdf)

---

# 17,000 actions inside Hugging Face: reading an agent breach as a containment problem

> An autonomous agent ran more than 17,000 actions inside Hugging Face, harvested stored credentials, and moved across internal clusters over a weekend. Here is the breach stage by stage, and what a governed agent layer changes at each one.

Published: 2026-07-21
Author: Edwin Ashdown
URL: https://agentvalet.ai/blog/hugging-face-agent-breach-blast-radius

![One foothold, four escalation steps, and the four controls that cap the blast radius.](/images/blog/hugging-face-breach-diagram.png)

In July 2026 Hugging Face [confirmed](https://huggingface.co/blog/security-incident-july-2026) that an autonomous agent had run more than 17,000 recorded actions inside its systems before the intrusion was contained. It is one of the first public cases of an AI agent carrying an operation end to end, and the detail that matters most is not the entry point. It is what the agent did once it was in.

The way in was an application vulnerability. A malicious dataset moved through the data-processing pipeline and exploited two code-execution bugs, a remote-code dataset loader and a template-injection in a dataset config, to run code on a processing worker. I want to be straight about this up front, because it sets the boundary for everything below. AgentValet does not patch your dataset loader. If the first step is remote code execution in your own pipeline, an authorization layer is not the control that stops it.

What an authorization layer changes is the second step, and the third, and every one after that. In this breach those steps are where a single compromised worker became 17,000 actions and a credential harvest across several internal clusters. That is a containment problem, and containment is the part you can design.

## The breach, stage by stage

Here is the disclosed sequence, and what a governed agent layer does at each stage.

**The worker was compromised, then the agent harvested cloud and cluster credentials.** This is the pivot that turned one foothold into a weekend of lateral movement, and it is the stage that changes most under a broker model. When an agent's platform access runs through AgentValet, the worker holds no platform credential to steal. The agent signs each call with its own identity key and a token that expires in a minute; the platform credential stays sealed in the vault and is attached in memory for that one call, then dropped. The single most valuable thing the attacker collected in this breach, stored service credentials sitting where a compromised process could read them, is the thing that no longer exists to collect. You cannot harvest a key that was never written down.

**The agent moved laterally into several internal clusters.** Lateral movement is broad authority reused past its purpose. Deny-by-default scoping is the direct answer. Every agent gets access to the exact endpoints its task needs and nothing else, matched at the endpoint rather than granted per whole connection, and bound to the specific user it is acting for. A compromised identity in that model reaches one system for one user, not several clusters. The move from a single worker to internal cluster after internal cluster is exactly the escalation that per-agent, per-endpoint attenuation is built to deny.

**The agent executed thousands of actions across a swarm of short-lived sandboxes.** An intrusion that explores at that volume does not run clean. It probes, it fails authorization, it hits errors as it maps what it can reach. For calls that go through a broker, AgentValet's circuit breaker trips on that signal: repeated auth failures or a run of API errors auto-suspend the agent. This breach didn't run through a broker, so this is a counterfactual, but a swarm probing permissions it doesn't hold through AgentValet would have been suspended on its first run of refusals, long before 17,000 actions, and without waiting for a human to notice. Sustained abnormal volume against valid scopes is the natural extension of the same tripwire, and it is the direction velocity limits point.

**High-impact actions ran without anyone in the loop.** Even inside a valid scope, the actions that cause real damage are a short list, and they should wait. AgentValet holds the irreversible ones (sending mail, moving money, deleting records) for an approval a person confirms with a passkey. An agent operating unattended over a weekend is precisely the case that gate exists for.

## Revocation measured in seconds, not a weekend

The Hugging Face intrusion moved over a weekend before it was contained. Dwell time is the currency of a breach, and revocation is what spends it down. AgentValet's revocation is cascading and near-instant. You can cut one agent's access to one platform, or all of it, in seconds, with no redeploy and no key rotation scramble, because there is no static key to rotate. The question every incident responder is asking in hour one, can I turn this off right now, has a one-word answer.

## The part most teams skip: you already have the trail

Reconstructing this attack meant pulling more than 17,000 events out of security telemetry and rebuilding the timeline. Hugging Face did it well, and fast, with AI-assisted analysis. But notice the shape of the work. The record had to be assembled after the fact from logs that were never designed to attribute a single agent's actions.

A brokered layer inverts that. Every call an agent makes is already a structured, attributable record: agent, user, action, target, and the policy decision that allowed it. You are not reconstructing what happened. You are reading it. When the question is which agent touched which system on whose behalf, that is a row, not a forensics project.

## The lesson buried in the response

The most quietly important detail in this incident is on the defensive side. When Hugging Face went to analyze the attacker's payloads with hosted commercial models, safety filters blocked the work. The attacker's agent operated with no such constraint. The defenders, using someone else's model under someone else's policy, were the ones who got told no. Hugging Face worked around it by running an open-weight model on its own infrastructure.

That asymmetry is the argument for keeping your governance evidence where you can reach it. Your containment layer, your audit trail, and your ability to analyze what happened should not sit behind a third party's acceptable-use policy at the moment you need them most. AgentValet is built with that in mind: the pieces that run on your machines are open source under MIT, and on Team and above the full audit trail exports to CSV, JSON, or PDF, so the record of what happened lives in your own tooling as well as ours. The whole point of the layer is to stop authority from spreading, and the evidence of whether it did should never be locked away from you.

## What this breach actually teaches

An agent got into Hugging Face through a code vulnerability, and no authorization layer would have changed that first step. What it teaches is what happened next. The foothold became a credential harvest because credentials were sitting there to take. One worker became several clusters because authority was broad enough to travel. The operation reached 17,000 actions because nothing capped the velocity, and it ran for a weekend because turning it off was not a one-second decision.

Every one of those is a design choice, and every one of them points the same way. Least privilege limits what a compromised agent can reach. [Least agency](/blog/least-agency-in-practice) limits how far it gets to act before someone is in the loop. This breach is what it looks like when neither one is enforced on the calls an agent makes. The agents you are running today already improvise at machine speed. The only question that decides your exposure is how much authority is waiting for them when one of them turns.

---

# Least agency in practice: scoping what an AI agent can do

> Least privilege limits what an agent can reach. Least agency limits how far it can act before it checks back. Here is how to apply it to real agents.

Published: 2026-07-08
Author: Edwin Ashdown
URL: https://agentvalet.ai/blog/least-agency-in-practice

You can hand an agent a perfectly scoped credential and still give it far too much rope. Scope decides which systems and operations it can touch. It says nothing about how many steps it gets to take on its own before a person is in the loop. A read-only agent can still loop a thousand times, chain calls nobody designed, and act on data it pulled from somewhere it had no business trusting. Least privilege is about reach. This post is about least agency, which governs how far an agent acts before it has to check back.

## What least agency actually means

Least agency is an OWASP principle from the 2026 Agentic Top 10 work: grant an agent only the minimum autonomy it needs for a safe, bounded task. Autonomy is earned per task. It is not inherited with a credential.

It sits alongside least privilege, and teams collapse the two constantly. They are different controls answering different questions.

| | Least privilege | Least agency |
|---|-----------------|--------------|
| Question it answers | What can this identity reach | How far can it act on its own |
| Unit of control | Scopes, roles, endpoints | Steps, decisions, autonomy per task |
| Failure it prevents | Over-broad access | Over-broad action |
| Classic control | RBAC, scoped tokens | Human approval, task bounds, revocation |

Least privilege has been standard practice for decades because the thing holding the privilege was a person or a fixed piece of software that did one predictable thing. An agent improvises. That is the part that breaks the old assumption.

## Why scoping access is only half the job

Give an agent write access to one system and you have controlled its reach. You have not controlled what it does with that reach. Inside a valid scope it can still take an action you never intended, run a sequence in an order no one designed, or repeat an operation until it does real damage. The credential was fine every single time. The agency behind it was the problem.

This is the shape of OWASP ASI03, Identity and Privilege Abuse, once you get past the identity label. Cached authority reused past its task. A privileged agent handing autonomy to a helper. A plan that was safe at step one and dangerous by step forty. None of that is an access failure. It is an agency failure.

## The dimensions you actually scope

Least agency in practice means putting a bound on each of these, per task, not once at setup.

1. **Actions.** Reading is not editing, editing is not deleting. Grant the specific operations the task needs and deny the broad ones by default. This is the least-privilege floor, and it is where least agency starts.
2. **Autonomy.** Decide how far the agent goes before a checkpoint. Low-impact and reversible work can run unattended. High-impact and irreversible work (sending mail, moving money, deleting records) waits on a human. That gate is the single biggest lever you have.
3. **Time.** Bind the credential to the task and let it expire with the task. A short-lived, keyless credential means there is no standing authority left over to be reused after the work is done.
4. **Person.** Decide what this agent may do on behalf of this specific user, not what the agent may do in general. A blanket per-agent grant cannot express that, and it is where borrowed access quietly becomes over-access.
5. **Reversibility.** The harder an action is to undo, the tighter the leash. Irreversible actions earn the least autonomy and the most oversight, every time.

## Least agency is the fastest lever you have

The earlier post in this series on identity as the control plane made the point that scoping autonomy moves an agent down the deployment axis of the OWASP maturity model. It is worth restating here because it is the practical payoff. An agent wired to external tools, scoped to one system, one user, and a five-minute credential, with a human on the risky calls, behaves like a far more contained deployment from a governance standpoint. You lowered its effective tier by shrinking its agency, without ripping the agent out.

That is why least agency is the control you can apply this afternoon. Raising your governance maturity across the board takes budget and quarters. Shrinking an agent takes a decision about what it is allowed to do on its own.

## What to do instead

If you are running agents against real systems, this is the order that reduces your blast radius:

1. **Set the action floor.** Grant the exact operations the task needs and deny the rest. Match access to endpoints, not whole connections.
2. **Pick the autonomy line.** List the actions that must never fire without a person, and gate them. Everything reversible and low-impact can run on its own.
3. **Make authority expire.** Short-lived, keyless credentials bound to the task, so nothing survives to be replayed later.
4. **Decide per user.** Bind the authorization to the person the agent is acting for, so a hijacked or confused agent stays inside one user's box.
5. **Keep the trail.** Agent, user, action, target. If you cannot reconstruct what an agent did and why it was allowed to, you have logging, not agency control.

This is the work an authorization layer does, and it is what AgentValet was built for. Instead of a raw API key, each agent gets its own signing identity and a grant you can narrow to single endpoints; the platform credential stays in the vault. It matches permissions down to the endpoint, runs a per-user policy engine that decides what each agent can do for each person, holds high-impact actions for a push approval confirmed with a biometric, and writes every call to an audit trail. The client-side pieces (the MCP server, the CLI, and the adapters) are MIT-licensed and public, which matters when the whole point is to stop authority from spreading.

## Shrink the agent, cap the bad day

Least privilege limits what a compromised agent can reach. Least agency limits how much damage it can do inside that reach before someone steps in. You need both, and the second one is the half most teams have not touched. The agents you are running today already make their own plans. The question that decides your exposure is how far you let them go before they have to ask.

---

# Your MCP server is holding a raw API token. Here is the three-line fix

> Most MCP servers keep a raw token in the handler and write it straight to the logs. Here is what that costs you, and the three lines of @agentvalet/mcp-broker that fix it.

Published: 2026-07-05
Author: Edwin Ashdown
URL: https://agentvalet.ai/blog/mcp-server-raw-token-three-line-fix

![Wrap the server once. Every tool after it is policy-checked, credential-injected, and audited.](/images/blog/mcp-broker-diagram.png)

Open almost any MCP server and you will find the same line near the top of a handler. A personal access token, sitting in a closure, ready to be handed to whatever tool call comes in next. It works on the first try, which is exactly the problem. The thing that makes it easy to ship is the thing that makes it dangerous.

Here is a GitHub-issues server written the way a lot of them actually get written.

```typescript
const token = process.env.GITHUB_TOKEN;   // full-scope PAT, lives in the closure

server.tool("create_issue", schema, async (args) => {
  log(`create_issue ${token} ${JSON.stringify(args)}`);   // token and args, straight to disk
  return await githubClient(token).issues.create(args);
});

server.tool("delete_repo", schema, async (args) => {
  return await githubClient(token).repos.delete(args);    // runs for anyone who can reach the server
});
```

Three things are wrong here and none of them are exotic.

The token is a full-scope credential, so every tool on the server can do everything the token can do. `create_issue` and `delete_repo` hold identical power, because they hold the same secret. There is no policy layer deciding that one of those is routine and the other should never happen without a human. And the only record of any of it is a log line that writes the token and the full arguments to disk, so your audit trail is also your worst leak.

## What that actually looks like when it runs

This is the log the insecure server produces. It is the real fixture from the example repo.

```json
{"ts":"…","tool":"create_issue","token":"ghp_EXAMPLE…","args":{"title":"Prod is down","body":"Customer X reports 500s since 08:50"}}
{"ts":"…","tool":"delete_repo","token":"ghp_EXAMPLE…","args":{"name":"acme/really-important-repo"}}
```

Read it back. The token is in the log, so anyone who can read the log has the credential. The issue body is in the log, so a customer report is now sitting in plaintext next to it. And the repo deletion already happened. No check, no approval, no way to have said no. The log is not a record of a decision. It is a record of a thing that was allowed to happen because nothing was ever asked.

## The fix is three lines

The same server, with `@agentvalet/mcp-broker` wrapped around it once.

```typescript
import { broker } from "@agentvalet/mcp-broker";

broker(server, {
  policy: "file:./policy.yaml",
  secrets: "env:",
  audit: "jsonl:./audit.log",
});

server.tool("create_issue", schema, async (args, ctx) => {
  return await githubClient(ctx.credential.token).issues.create(args);
});
```

You import `broker`, you call it once before you register your tools, and inside the handler you read `ctx.credential.token` instead of a module-level secret. Every tool you register after that call runs through the same pipeline: resolve the caller identity, evaluate the policy, hold for approval if the policy says so, resolve a narrow credential for that one call, run the handler, then audit it. You did not restructure a single tool. You wrapped the server.

The policy is a small file, deliberately boring.

```yaml
version: 1
defaults:
  effect: deny
rules:
  - tool: create_issue
    effect: allow
    credential: github_issues_rw
  - tool: delete_repo
    effect: require_approval
    credential: github_admin
```

Deny by default. `create_issue` is allowed. `delete_repo` needs a human. Anything you did not write a rule for does not run.

## The same run, now audited properly

Here is the after log. Same client, same three calls, plus one call for a tool nobody ever wrote a rule for.

```json
{"resource":{"tool":"create_issue"},"argsFingerprint":"sha256:3431…","decision":{"effect":"allow"},"outcome":"allowed","warnings":["credential_no_expiry_static_secret"]}
{"resource":{"tool":"export_secrets"},"argsFingerprint":"sha256:ad91…","decision":{"effect":"deny"},"outcome":"denied"}
{"resource":{"tool":"delete_repo"},"argsFingerprint":"sha256:2ca1…","decision":{"effect":"require_approval"},"outcome":"approval_timeout"}
```

Four things changed, and each of them maps to one of the problems from before.

There is no token anywhere in the log. The handler gets a resolved credential at call time and never holds a standing secret. `create_issue` ran, and the `credential_no_expiry_static_secret` warning is the broker pointing out that a local `env:` secret is static, which is your nudge toward a real short-lived credential later.

There are no raw arguments in the log, only a `sha256` fingerprint. You can still correlate calls, spot a repeat, prove two requests carried the same payload, all without the payload itself ever touching disk.

`export_secrets` was denied by default. Nobody wrote a rule for it, so it did not run, and the attempt is on the record. That is the deny-by-default posture doing its job on a tool the author never even thought about.

`delete_repo` was held for a human. With no approval it timed out and was denied, logged as `approval_timeout`. The repo is still there. The dangerous action became a decision instead of an event.

## Why this is a library and not a gateway

Most tools in this space are gateways. You stand up a proxy or a runtime in front of your MCP servers, a platform team owns it, and it governs traffic on the way through. That model is fine when a platform team exists and a gateway is going to get deployed.

For most MCP servers, neither of those is true. The server is one file, written by one person, shipped on its own. A gateway will never sit in front of it. A library can live inside it. That is the whole idea here. Governance that an individual server author adopts with one dependency and one function call, not infrastructure that an org has to stand up first.

## Local mode is genuinely free, and honest about where it stops

The example above uses no account and no network. Policy from a YAML file, secrets from the environment, audit to a local JSONL file. For one developer and one server, that is a complete and useful setup, and it stays free.

It is also deliberately built to stop scaling at exactly the point where a team needs more. The YAML format has no environments, no inheritance, no templating, and no record of who changed a rule. The moment you want approval routing, versioned rollout, a central audit store, or a real short-lived credential minted per call instead of a static secret, those are the hosted plane. The local policy you write evaluates with byte-identical semantics to the hosted one, because it is literally the same evaluator. You are not migrating off a toy when you upgrade. You are keeping the same rules and moving where they run.

## Try it on your own server

If you maintain an MCP server, the whole change is one install and three lines.

```bash
npm install @agentvalet/mcp-broker
```

Wrap your server, write a five-line policy, point audit at a file, and read `ctx.credential` in your handlers. It is MIT licensed, has zero runtime dependencies, and the before-and-after example with both audit logs is in the repo so you can see the full diff before you touch your own code. The token comes out of your handler, the dangerous tools start asking first, and your logs stop being the thing you are most afraid of leaking.

---

# Authentication or authorization: which problem are you solving for AI agents

> Identity vendors solve authentication for AI agents. ASI03 lives in authorization. Here is the difference and why agents need the second layer.

Published: 2026-07-01
Author: Edwin Ashdown
URL: https://agentvalet.ai/blog/agent-authentication-vs-authorization

![Authenticate once at call zero, then authorize every call after.](/images/blog/auth-vs-authz-diagram.png)

Every agent identity pitch sounds complete until you ask it one question. Once the agent proves who it is, what stops it from doing the wrong thing. Most of the market has a confident answer for the first half and a shrug for the second. That split, authentication against authorization, is the most important distinction in agent security right now, and it is the one teams collapse the fastest.

## Authentication is who. Authorization is what.

Authentication is an agent proving its identity. A certificate, a signed token, a registration record, something that says this request really came from the invoicing agent and not an impostor. Authorization is the decision that comes after: what is this proven identity allowed to do right now, on whose behalf, and for how long.

Here is the part that gets lost. An agent authenticates once and then makes a thousand calls. The authentication event happened at call zero. Every call after that is an authorization question, and most stacks never ask it again. They check the badge at the door and then let the holder roam the building for the rest of the day.

## The market sells you authentication and calls it done

Identity vendors are genuinely good at issuing agents identities. Okta, Entra, and a wave of agent-identity startups will give every agent a distinct, verifiable name, often backed by a certificate. That work is necessary and I am not knocking it.

But a valid identity says nothing about scope, purpose, or duration. An agent can hold a pristine credential and still drain a system, because the credential was broad and nobody decided what it was actually for. Issuing the identity is the start of the job. The market keeps shipping the start and presenting it as the finish.

## ASI03 is an authorization problem wearing an identity label

OWASP's ASI03, Identity and Privilege Abuse, is the identity risk in the Top 10 for Agentic Applications. Read its failure modes and they are all authorization failures in disguise:

- **Cached credentials reused across sessions.** The token was valid. Nothing scoped it to a single task or expired it fast enough.
- **A privileged agent handing full credentials to a lower-privileged one.** Both authenticated cleanly. The delegation carried far more authority than the handoff needed.
- **A borrowed user session acting three hops from the request.** The session was real. No layer checked whether this action, for this user, was still in bounds.

In every case the agent was who it claimed to be. The breakdown was in what it was allowed to do.

## The valet key test

A valet key starts the car and opens the door. It will not open the glovebox or the boot, and it stops working when you take it back. The attendant is authenticated, clearly the person driving your car into the garage. Their authority is scoped to exactly that task.

Authentication is the attendant being who they say. Authorization is the key turning the ignition and nothing else. Agents today mostly get handed the house key, which opens everything, and then we act surprised when one of them wanders into a room it had no reason to enter.

## How to tell which problem you have actually solved

Run this on any agent in your stack:

1. **Can it prove who it is?** If yes, you have authentication.
2. **Is its access scoped to a user, a set of endpoints, and a time window?** If no, you have not solved authorization.
3. **Can a high-impact action be held for a human?** If no, your authorization is partial at best.
4. **Can you revoke it in seconds and replay every action it took?** If no, you have identity without control.

Most teams answer yes to the first and no to the rest. That is an authentication win sitting on top of an authorization gap, and ASI03 is exactly the shape of that gap.

## What to do instead

1. **Treat identity as the foundation, not the finish.** Issue every agent its own identity, then build the decision layer on top of it.
2. **Scope at the authorization layer.** Bind each credential to one user, a set of endpoints, and a tight window. Keyless and short-lived, so there is no standing secret to replay.
3. **Decide per user.** The question is what this agent may do on behalf of this specific person, which a blanket per-agent grant cannot answer.
4. **Gate the expensive actions.** Sending mail, moving money, deleting records. A human approval on those beats trusting the prompt held.
5. **Keep a trail you can hand an auditor.** Agent, user, action, target. If you cannot reconstruct who did what, you have logging, not authorization.

This is the work an authorization layer does, and it is the half AgentValet was built for. It checks every call an agent makes against the scopes you granted that agent, keeps the platform credential in its vault rather than in the agent's hands, runs a per-user policy engine that decides what each agent can do for each person, holds high-impact actions for a push approval confirmed with a biometric, and writes every call to an audit trail. The one-line version: identity vendors prove who the agent is, AgentValet decides what it is allowed to do.

## Solve the half that decides your blast radius

Authentication was always going to get solved. There is a market for it, there are standards for it, and the identity vendors are good at it. Authorization is the half that decides what a compromised or confused agent can actually reach, and it is the half you have to enforce on every call, not once at the door. If your agent can prove who it is and still do anything, you have answered the easy question and left the dangerous one open.

---

# Identity is the control plane for AI agents

> OWASP's 2026 report makes agent identity the control plane. What that means for governing AI agents at runtime, and where most setups stop short.

Published: 2026-06-24
Author: Edwin Ashdown
URL: https://agentvalet.ai/blog/agent-identity-control-plane

![Identity tells you who an agent is, not what it is allowed to do.](/images/blog/identity-control-plane-diagram.png)

You gave your AI agent its own identity and you were told that was the hard part. You registered it, issued it a credential, maybe put it behind Okta. Then you connected it to Slack, Gmail, and Stripe with the same broad token a human operator would carry, and moved on. The identity is real. The access sitting behind it is still a house key.

That gap is the whole problem, and OWASP spent its 2026 report describing it.

## Identity tells you who. It doesn't tell you what.

Authentication answers who an agent is. That part has a healthy market and it mostly works. You can issue every agent a distinct, verifiable identity and attach a certificate to it.

Authorization answers a different question: what is this authenticated agent allowed to do right now, on whose behalf, and for how long. OWASP ASI03, Identity and Privilege Abuse, lives almost entirely in that second question. An agent with a perfectly valid identity can still reuse a cached token across sessions, pass its credentials to a lower-privileged helper agent, or act on a borrowed user session three hops from where the request started. The name on the request was never the issue. The standing access behind it was.

## OWASP moved the goalposts in 2026

The State of Agentic AI Security and Governance 2026, published on 1 June, gives agent identity its own chapter and calls it a control plane. A control plane is just the place where you decide and enforce what something can do. Identity is that place for agents, because policy, audit, and revocation all hang off it.

The numbers behind the framing are worth keeping:

- **Non-human identities outnumber humans by around 100 to 1.** Service accounts, workloads, and agents now vastly outnumber people, and agents are the fastest-growing slice.
- **About 37 percent of organizations have any policy to manage AI or detect shadow AI.** That figure is from a survey OWASP cites. Most teams cannot yet see the agents already running on their data.
- **ASI03 has the widest readiness gap of any category.** It scored the largest distance between how severe the risk is and how prepared anyone is for it.

Put those together and you get a layer that every company now depends on and almost nobody governs.

## Two axes, and most teams only watch one

The report ships a maturity model with two axes, and the point is to compare them.

- **Adoption tier, AT0 to AT8.** What are you running. AT0 is shadow AI, unmanaged usage already on your data. The scale climbs through vendor assistants, citizen-developer flows, code-executing agents, agents wired to external tools over MCP, up to AT8 federated systems that cross organizational boundaries.
- **Governance maturity, Level 0 to 4.** How well can you see and stop it. Level 0 is ad hoc and unaware. Level 4 is real-time oversight with kill switches and machine-readable policy.

Then you cross them. An AT8 federated deployment sitting on Level 0 governance reads as do not deploy. Shadow AI at AT0 reads as critical, because you cannot govern usage you have not found. Most teams obsess over the deployment axis, ship the impressive agent, and never once score their governance against it.

## When governance can't keep up, shrink the agent

OWASP gives two ways to close a gap. Raise governance maturity, which costs real time and budget. Or reduce the agent's permissions and autonomy until the controls you already have are enough.

The second one you can do this afternoon. An agent wired to external tools at AT6, scoped to a single system, a single user, and a five-minute credential, behaves like a contained AT2 deployment from a governance standpoint. You lowered its effective tier by scoping its authority, without ripping it out.

This is the principle OWASP calls least agency. Least privilege limits what an identity can reach. Least agency limits how far it can act before it has to check back. Scoping autonomy is the lever that moves an agent down the deployment axis.

## What to do instead

If you are wiring agents into real systems, this is the order that actually reduces your blast radius:

1. **Find your shadow AI first.** Assume AT0 exposure exists until proven otherwise. You cannot govern an agent you have not discovered.
2. **Give every agent its own identity.** Stop agents borrowing a human's OAuth session, which drags a person's full standing access into every action.
3. **Scope the credential and make it short-lived.** Bind it to one user, one set of endpoints, and a tight window. Keyless, so there is no standing secret to copy or replay.
4. **Decide per user, not per agent.** Authorization should answer what this agent may do on behalf of this specific person. A blanket per-agent grant cannot express that, and it is where borrowed access quietly becomes over-access.
5. **Gate the expensive actions behind a human.** Sending mail, moving money, deleting records. A push approval confirmed with a biometric beats hoping the prompt held.
6. **Keep an audit trail that names names.** Agent, user, action, target system. If you cannot answer who did what after the fact, you do not have authorization, you have logging.

This is the point where a broker earns its keep. AgentValet sits between your agents and the platforms they call, and the agent never holds a raw API key. It proves who it is by signing each call with its own key; the platform credential stays in the vault and is attached for that one call. Permissions match down to the endpoint, a per-user policy engine decides what each agent can do for each person, high-impact actions wait on a push approval confirmed with a biometric, and every call lands in an audit trail. The client-side pieces (the MCP server, the CLI, and the adapters) are MIT-licensed and public, which matters when the entire goal is to stop credentials from spreading.

## Identity is the starting line

Once every agent has a name, the question that decides your exposure is what that name is allowed to do, for whom, and for how long. That is the control plane, and issuing identities is only the moment you reach it. A clean directory of agents that can each do anything is not governance. Put the authorization decisions on the identity, enforce them at runtime, and the control plane starts earning the name.

To see where your agents sit today, the [Agent Exposure Scorecard](/agent-exposure-scorecard) runs this as an eight-question check mapped to the 2026 OWASP agentic risks, and shows your exposure score with no email.

---

# Why your AI agent shouldn't have your API keys

> Handing an AI agent a raw API key gives it permanent, unscoped, unauditable access to your accounts. Here's the risk, and what to do instead.

Published: 2026-06-14
Author: Edwin Ashdown
URL: https://agentvalet.ai/blog/why-your-ai-agent-shouldnt-have-your-api-keys

![An API key handed to an AI agent grants unscoped, permanent, unauditable access.](/images/blog/api-keys-diagram.png)

You wired up an AI agent last week. To let it do real work (file a ticket, send an email, pull a report) you did the obvious thing: you pasted an API key into its config.

It worked. The agent got things done. But you just handed a non-deterministic program a credential that, in most systems, means *full access, forever, with no record of who did what.* That trade is worth a second look before you do it again.

## What an API key actually grants

An API key is a bearer token. Whoever holds it *is* you, as far as the platform is concerned. That has three properties that are fine for a backend service and dangerous for an autonomous agent:

- **It's unscoped.** Most keys carry the full permissions of the account that minted them. A key you created to let the agent read your calendar can usually delete it too. The agent doesn't need that power; the key grants it anyway.
- **It's permanent.** Keys don't expire on their own. If the agent is compromised through a prompt injection, a poisoned tool result or a leaked log, the attacker has the key until *you* notice and rotate it. Agents fail in novel ways, and they fail quietly.
- **It's unauditable.** When the platform logs the action, it sees the key, not the agent. You can't answer "which agent did this, on whose behalf, and was it allowed?" because the key erased that distinction the moment you handed it over.

For a human, you'd never accept this. People get scoped roles, SSO, approval steps for risky actions, and an audit trail. Agents have been getting raw keys because it was the fastest way to make them work, not because it was safe.

## Why agents make this worse than normal

A traditional integration does the same thing every time. An agent decides what to do at runtime, based on text it was given, some of which may come from the open internet or from another system you don't control. That means the *instructions* an agent follows are an attack surface, and the API key is the blast radius.

If a malicious document can talk your agent into calling a tool, then whatever that tool can reach, the attacker can reach. Scope the credential down and the worst case shrinks. Leave it as a full-access key and the worst case is your whole account.

## What to do instead

The fix isn't to stop using agents. It's to stop letting the agent hold the secret. A few principles get you most of the way:

1. **Put a broker between the agent and the platform.** The agent asks the broker to perform an action; the broker holds the real credential and makes the call. The secret never lands in the agent's context, its config, or its logs.
2. **Scope every grant to the action.** Give the agent permission to *send a Slack message in #support*, not all of Slack. Deny by default; allow specific actions explicitly.
3. **Require approval for the irreversible stuff.** Reading data can be automatic. Route spending money, deleting records and emailing customers through a human who approves each one, with the request shown in plain language.
4. **Give the agent its own identity.** When every call is attributed to a specific agent acting for a specific person, your audit log finally answers the question that matters: *who did this, and were they allowed to?*
5. **Make revocation instant.** If an agent misbehaves, you should be able to cut its access in one place, without rotating a key that ten other things depend on.

## The shift underneath all of this

Stop trying to make the agent trustworthy enough to hold a master key. Assume it can be fooled, and put the controls where you actually have leverage: between the agent and the world. Trust the broker, not the agent.

That's the model AgentValet is built on: scoped, identity-bound, human-gated, fully audited access for AI agents, with the real credentials kept in a vault the agent never sees. If you're handing agents API keys today, that's the habit worth replacing first.

If you want to see where your own agents stand, the [Agent Exposure Scorecard](/agent-exposure-scorecard) turns these five principles into an eight-question check mapped to the OWASP Top 10 for Agentic Applications 2026, with your score and the fix for each gap.