Notifications
Clear all
Topic starter
22/06/2026 9:59 am
TL;DR: AI coding agents need credentials to do useful work, but exposing raw secrets to model context increases leakage and blast radius, according to 1Password. Runtime issuance, task scoping, and centralised credential control preserve developer velocity without handing plaintext secrets to the agent.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams handle secrets when AI coding agents need access?
A: Security teams should keep raw secrets out of agent prompts and instead issue task-scoped credentials through a governed runtime layer.
Q: When does secret rotation fail to reduce risk in agentic development?
A: Rotation fails when the real problem is exposure, not longevity.
Q: What do teams get wrong about using .env files with AI agents?
A: Teams often treat .env files as harmless developer convenience, but for AI agents they become a direct secret distribution channel.
Practitioner guidance
- Remove plaintext secrets from agent workflows Block direct secret injection into prompts, context windows, .env files, and generated code paths.
- Bind credentials to task scope and expiry Issue secrets only for the specific development task, then revoke them automatically when the task ends.
- Inventory and refactor hardcoded secret locations Search repos, scripts, and configuration files for embedded keys and replace them with references to managed secrets.
What's in the full announcement
1Password's full research covers the operational detail this post intentionally leaves for the source:
- How the 1Password Environments MCP Server is wired into Kiro for runtime credential handling
- The specific workflow for replacing hardcoded secrets with managed references inside developer environments
- Operational details on how task-scoped credentials expire when the work ends
- The broader AWS integration footprint that the article says underpins this access model
👉 Read 1Password's analysis of runtime secrets for AI coding agents in Kiro →
AI coding agents and runtime secrets control in Kiro?
Explore further
22/06/2026 10:41 am
Task-scoped credentials are the right baseline for AI coding agents because standing secrets assume a human-paced workflow. That assumption breaks when an agent can act continuously, reuse context, and surface secrets in output. The governance implication is that access provisioning, review, and revocation need to be tied to task completion rather than to a user's broader development session.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
A question worth separating out:
Q: How should IAM teams govern AI agent access differently from human developer access?
A: IAM teams should govern AI agents as runtime consumers of access, not as users with durable credentials. That means binding privileges to the task, not the identity alone, and maintaining approval, revocation, and logging around the access event. The control objective is to prevent the agent from becoming a standing secret holder.
👉 Read our full editorial: Runtime credential controls for AI coding agents in Kiro
