AI agent credentials: trace the tool, issuer and responder

Substantially revised October 4, 2026. The earlier article described a repeatable rise in secret-detection events after agent integrations were enabled and called it a field observation from customer environments. Its own editorial outline said that claim required confirmation in telemetry before publication. We could not establish a reproducible cohort, measurement window or supporting record, so that claim and the invented convenience-key timeline have been removed.

Does an agent create a new credential for every action?

No. An agent workflow may call several tools using a delegated user grant, a workload identity, a service token or a static API key. The same credential can authorize many calls, and a single workflow can cross multiple issuers. The agent is an actor in the workflow; a key is one possible means of authorization. Count actual credentials and permissions, not prompts or tool calls, when assessing exposure.

For each integration, identify the tool or API called, which principal the issuer recognizes, how the grant is obtained, where any reusable secret is stored, its expiry, and the resource and action scope. Record the person or service responsible for the integration separately from a source-file author and from the user who asked the agent to act. The current responder may be different from all three.

Trace one call across its trust boundaries

Suppose an agent reads a ticket and calls a cloud API through a tool. First establish whether the ticket content is data or an authorized instruction. Then inspect the tool configuration and the credential or workload identity used for the cloud call. Check its issuer, audience or target, permissions, and activity logs. A successful tool call shows that an action occurred; it does not by itself identify who approved it or prove that the same key is stored in every connected system.

MCP authorization has continued to evolve. The July 2026 protocol release hardened issuer validation and credential separation across authorization servers. Inspect the version and implementation used by the actual client and server; the existence of an MCP connection alone does not tell you how a downstream API is authorized.

Where to look for exposure

Start with connected repositories, build files, ticket text, chat threads and storage objects that may contain a reusable value. A finding in one of those places establishes a source location, not that the agent used the value at runtime. Compare it with the issuer record, the deployed tool configuration and relevant audit logs. A key in a local-only config, process memory or an unconnected CI variable store will not appear just because a different repository is connected to a scanner.

For a supported credential type, check its current validity through the issuer and record the time of that check. Where available, review actual permissions and recent use. An inactive result today does not rule out earlier access; an unresolved check is not evidence that the key is safe. If a sensitive value may still work, the service owner should coordinate containment at the issuer and update verified consumers before removing the old value.

Controls to test in the agent workflow

Use temporary credentials and workload roles where the service supports them; AWS recommends temporary credentials instead of long-term IAM user access keys when possible. Restrict grants to the tools and resources required for the task. Keep privileged side effects behind an approval or policy boundary and log the proposed action, calling identity, decision and result. OWASP’s prompt-injection guidance also recommends least privilege and human approval for high-risk actions because external content can influence tool use.

Test the controls against a concrete workflow: what can the agent read, write, grant or send outside the organization? Which tool enforces that limit? If the model receives a malicious instruction in a ticket or document, does the tool still reject an out-of-scope action? A prompt that says “do not” is not an access-control boundary.

What Cremit can show

Cremit Platform can find agent-related keys or tokens when they appear in supported connected sources. It checks supported credential types for validity, can analyze access scope for supported AWS and GCP keys, and provides evidence for an owner to investigate. It does not discover every agent, infer which agent created or used every key, inspect arbitrary local configuration or process memory, enforce tool-call policy, or rotate and revoke credentials automatically. Use its finding as one input to the issuer and workflow records above.

Primary sources

AWS IAM — Manage access keys and prefer temporary credentials

Model Context Protocol — July 2026 specification release

OWASP LLM01:2025 — Prompt Injection