An agent does not need to leak a credential to misuse it. Separating credential visibility from credential usability is the key to controlling the damage.
Part of the Grok Bot security series.
Basis of this analysis. Written from public vendor documentation (xAI, Cursor, Meta) and published reporting on the x47.c tool (Qrator Research Labs, via Infosecurity Magazine and SecurityWeek). HexTyx is a security vendor. The testing described below used synthetic data and our own apps, not Grok Bot or Meta Muse.
An AI agent rarely needs to leak a credential to be dangerous with one. If it can act through an authenticated session, call a connector or edit a script that a trusted process runs, the credential's authority is effectively the agent's authority. This article is about that gap between a secret being hidden and a secret being unusable.
| Question | Credential visibility | Credential usability |
|---|---|---|
| What it asks | Can the agent read the secret? | Can the agent cause something to be done with it? |
| Typical control | Masking, redaction, keeping tokens off the host | Scoping, short lifetimes, approvals, egress rules |
| Failure | The secret appears in output or logs | The agent performs an action the secret authorizes |
| Common blind spot | Treated as the whole problem | Rarely tested |
Grok Bot's documentation illustrates the distinction well. Secrets are masked, excluded from the transcript and not shown to the model, and connector tokens stay on Cursor's backend. Those are real protections for visibility. The same documentation also says files, browser sessions and command-line credentials on the user's shared computer are available across the Bot roster. Hidden secrets and usable sessions coexist. See Grok Bot Shared Workspace Security for that side of it.
Layers 2 to 4 do not need the agent to see anything. Controls built only for layer 1 miss them. This ties into non-human identity management and AI agent permissions.
A steered agent can use an authorized tool in an authorized way for an unauthorized purpose. The call is well-formed and permitted, and the credential is genuine. Nothing in the credential system objects.
HexTyx has seen this in testing. In our Vault app (synthetic data, live LLM agent), an injected fake confirmation led the agent to move $5,000, and in other tests it unmasked a card number and accessed another account. In our Concord app, a fake confirmation produced a medication order on a warfarin patient. In our Mercury app, the agent sent a zero-click exfiltration email. In each case the agent used access it legitimately had. These are results from our own apps, not from Grok Bot or Meta Muse.
API keys for AI services have direct cash value. OWASP's term for abusing metered services to run up a bill is "denial of wallet." A leaked key doesn't need to expose data to be costly.
x47.c is a malware-as-a-service tool analysed by Qrator Research Labs (published September 23, 2026) and reported by Infosecurity Magazine and SecurityWeek. Its seller uses the name "WraithTools." The reported "AI API drain" feature needs an operator-supplied valid API key and model name for OpenAI, xAI or compatible chat APIs. Requests go directly to the provider, bypassing the victim's app. Qrator also reported finding no test results supporting some advertised protection-bypass features.
That has three implications.
These are HexTyx recommendations.
For approval design, see circuit breakers for rogue AI agents and AI agent kill switch and dead man's switch.
Revoke before investigating. Then check what the credential could reach, not just what it did, because an agent can have done more than the logs show. See AI security incident response.
Track unusual volume, new destinations, off-hours use and model or endpoint changes. For AI keys, spend is the earliest signal.
Run the free playground scanner against your AI application, or read the other guides in this series.