CybersecurityAWS AgentCore Prompt Injection and Credential Exposure: Securing Tool-Enabled AI Agents
Unit 42 showed how prompt injection against permissive AWS AgentCore configurations could expose plaintext credentials available to an agent runtime. The research highlights shared-responsibility controls around tools, egress, identity scope and untrusted content.
Verified for technical accuracy — Kodi C.
Archive coverage note: This Zeph Tech briefing was published on September 27, 2026 and documents a security development from . The historical date in the URL identifies the covered event; it is not a claim that Zeph Tech originally published the page on that date.
An AI agent becomes materially more dangerous when it can call a shell, reach external networks and inherit powerful credentials. Prompt injection then stops being only an output-quality problem and becomes a path to misuse real operating-system and cloud authority.
What happened
Palo Alto Networks Unit 42 analyzed AWS AgentCore runtime configurations and demonstrated how an agent with shell access in the same environment as plaintext identity credentials could be manipulated by malicious instructions. The research focuses on insecure or overly permissive customer configurations rather than claiming that every AgentCore deployment is vulnerable by default.
- Unit 42's demonstration combined prompt injection with shell-capable tools and accessible runtime credentials.
- The research emphasizes controls such as restricting allowed tools, limiting egress and scoping identity permissions.
- Agentic runtimes can cross traditional application boundaries because the model can invoke tools instead of merely returning text.
- The findings are framed within cloud shared responsibility: platform safeguards and customer configuration both matter.
Why defenders should care
Many organizations are connecting agents to cloud APIs, databases, ticketing systems and internal tools before establishing mature authorization patterns. If untrusted content can influence a tool-enabled agent, excessive permissions can turn one malicious prompt into data access or credential exposure.
- Shell or code-execution tools can expose secrets available in process memory, files or environment variables.
- Broad outbound network access can enable exfiltration to attacker-controlled destinations.
- Overprivileged agent identities increase the consequence of a successful prompt-injection chain.
- Traditional application testing may miss attacks that arise from the model's interpretation of retrieved content.
Priority response
Organizations should translate this development into a controlled security workflow: identify affected assets and trust relationships, reduce unnecessary exposure, apply the relevant vendor or architecture controls, and verify the outcome with evidence rather than assuming a configuration change was successful.
- Inventory every tool exposed to production agents and remove shell, code or network capabilities that are not required.
- Apply least-privilege IAM policies specifically for the agent's task instead of reusing broad application roles.
- Restrict outbound destinations with network and application-layer controls where the workflow permits it.
- Separate secrets from the agent's direct runtime context and prefer short-lived credentials delivered only when needed.
- Test indirect prompt injection through documents, webpages, messages and records the agent actually consumes.
- Log tool calls, identity use, outbound destinations and the initiating request so investigators can reconstruct agent behavior.
Detection and verification
Monitor for agent-initiated shell execution, access to credential locations, unusual metadata or token requests, outbound traffic to new domains, sudden permission errors followed by alternate actions, and cloud API calls that fall outside the agent's expected task profile.
Preserve the telemetry needed to establish a timeline before making disruptive changes when practical. Correlate identity, host, application, cloud and network signals so the team can distinguish a blocked attempt from successful access and can identify follow-on behavior.
Longer-term security lesson
Prompt injection becomes high impact when the model has excessive authority. Secure agent architecture therefore starts with conventional security engineering: least privilege, secret isolation, egress control, explicit tool allowlists, auditability and human confirmation for consequential actions.
For program owners, the recurring requirement is evidence: know which systems are affected, which owner is accountable, what control was changed, and what proves the residual risk is acceptable. That discipline turns a fast-moving advisory into repeatable security operations.
Questions teams should be able to answer
Is AgentCore itself inherently unsafe?
No. The research demonstrates dangerous combinations of tools, credentials and permissive configuration. The relevant question is whether a specific deployment exposes capabilities that malicious instructions can abuse.
Why is shell access especially risky?
A shell can bridge the model into the host operating system, making environment variables, files, processes and network utilities available unless separately restricted.
Can prompt filtering solve this alone?
No. Content filtering is useful, but strong authorization and runtime isolation limit impact even when malicious instructions reach the model.
Related Zeph Tech guidance
Use the Vulnerability Management Program guide to operationalize urgent security changes, the free cybersecurity risk register to assign residual exposure and treatment ownership, and the Cybersecurity hub for broader defensive guidance.
Scope the operational blast radius
Document the full AgentCore trust boundary: who can invoke the runtime, what payload structures are accepted, which tools are available, what execution-role permissions exist, which secrets the runtime can retrieve and where outbound traffic can go. Prompt injection becomes dangerous when untrusted instructions can reach capabilities that were granted for legitimate automation.
Retain runtime invocation logs, tool-call traces, IAM activity, AgentCore Identity events, outbound network telemetry and changes to runtime configuration. Test both direct prompts and indirect content from files, webpages or retrieved records. Record the exact role and tool configuration used in each test so later changes can be revalidated.
Turn remediation into an auditable control
Follow AWS guidance on input validation, restrict invocation to intended gateways or principals, use narrow execution roles, prefer AgentCore Identity for third-party credentials, run containers without unnecessary privilege and constrain outbound network access. Treat shell or code-execution tools as exceptional capabilities that need a documented reason and separate monitoring.
Measure whether the control is improving instead of counting closed tickets. Useful indicators for this topic include runtimes exposing shell or arbitrary code tools; execution roles with wildcard permissions; external destinations reachable from agents; prompt-injection regression pass rate; tool calls lacking initiating-user context; and time required to revoke a compromised agent identity. Review the measures after material architecture changes and after incidents so the program does not optimize for a stale threat model.
A 30-day follow-through check
Revisit the issue after the emergency response window. Confirm that temporary containment has either been removed safely or converted into a supported permanent control; that every affected asset has a recorded owner and final disposition; that credential or identity changes reached dependent systems; and that detection logic still produces useful telemetry. Capture any missed inventory, unclear ownership, failed rollback, logging gap or dependency discovered during the event as a concrete improvement item. The goal is to leave the organization with a smaller attack surface and a faster future response, not merely a closed advisory.
Owner handoff before closure
Before closing the response to AWS AgentCore, the technical owner and the risk owner should agree on what evidence demonstrates completion. Record the affected inventory, final software or configuration state, temporary controls still in place, credentials or identities changed, detection coverage added, and any systems excluded from remediation with an explicit reason. Confirm that monitoring will detect recurrence and that the service owner knows which future change would invalidate the current risk decision. If the event exposed an inventory, logging, ownership or recovery gap, assign that gap as separate tracked work instead of burying it inside the original patch ticket. A short post-response review should also capture which step consumed the most time and which dependency prevented faster action. That information is operationally valuable: it lets the next incident start with a tested owner map, reliable evidence sources and a known containment path rather than repeating discovery under pressure.
Cited sources
- Securing AWS AgentCore Harness Credentials From Prompt Injection — Palo Alto Networks Unit 42
Continue in the Cybersecurity pillar
Return to the hub for curated research and deep-dive guides.
Latest guides
-
Network Security Fundamentals: Segmentation, DNS, Zero Trust & Monitoring | Zeph Tech
A 2026 practitioner guide to network segmentation, firewall policy, DNS security, remote access, encrypted traffic, monitoring, administration, and zero-trust architecture.
-
Small Business Cybersecurity Survival Checklist
A practical 2026 cybersecurity operating guide for small and medium-sized businesses, organized around NIST CSF 2.0 and current FTC guidance with bounded Verizon DBIR threat…
-
Cybersecurity Operations Playbook
Build a defensible cybersecurity operations program around NIST CSF 2.0, current incident-response guidance, exploited-vulnerability prioritization, evidence capture, and…
Coverage intelligence
- Published
- Coverage pillar
- Cybersecurity
- Source credibility
- 40/100 — low confidence
- Topics
- AWS AgentCore · Prompt injection · AI agent security · IAM · Cloud security
- Sources cited
- 2 sources (unit42.paloaltonetworks.com, docs.aws.amazon.com)
- Reading time
- 6 min
Cited sources
- Securing AWS AgentCore Harness Credentials From Prompt Injection — Palo Alto Networks Unit 42
- Security best practices for AgentCore Runtime — Amazon Web Services
Source feedback
Editorial
Found a factual issue, superseded source, broken citation, or important context we should review? Send the specific claim and supporting source through the correction path so it can be evaluated against the article record.