A Vault with a Heap-View: The Uncomfortable Space Between AgentCore Harness and Identity

by Niv Rabin

AgentCore Identity stores credentials for your agents. You reference them by ARN, the plaintext stays on the AWS side, and everything is encrypted and behind IAM. Niv wanted to know what happens at the moment the harness actually needs to use one. He put a hidden HTML comment in a support ticket telling the agent to curl a script and run it. The harness shell tool is enabled by default and runs as root, so the script read the harness process's memory and pulled the plaintext JWT straight out of the heap. From his laptop, with no AWS access, he used that token to call the downstream MCP server. AWS closed it as informative and pointed at allowedTools, which only applies when you invoke the harness, not when you create it. I get it, the harness is meant to be easy to use and full featured but surely making the default prompt injection case code execution is not a good idea?

Part 4: AWS SageMaker AI, SageMaker Unified Studio & App Runner (Escalating Privileges via AWS CodeConnections)

by Thomas Preece

CodeConnections is what lets CodePipeline, CodeBuild and SageMaker reach into your GitHub or GitLab repos. Thomas has spent months working out how much access that actually hands over. In CodePipeline, the full clone option means the CodeBuild role gets codeconnections:UseConnection, and that single permission can push and pull any repository the connection can see, not just the one the pipeline is for. The undocumented API the console uses lets the same permission list, create and delete repositories. This post takes that to SageMaker. The managed roles AWS creates for Unified Studio and the MLOps templates grant UseConnection with only a tag condition, so anyone who can run code in a Unified Studio notebook, or in the MLOps pipelines, gets the same reach into your source control. The conditions to fix this exist. AWS just doesn't set them.

Exploring the new AWS Sign Up experience

by Scott Piper

The Cloud Historian is back in ASD. AWS changed how new accounts get created and Scott went through it to see what you actually end up with. It's three accounts in an organization: one for you, a management account that applies the SCPs and RCPs, and an identity account. You only see yours until you upgrade. Sign-in is a Builder ID with an emailed code, so there's no root user to lose. There's a $20 budget wired to an SCP and an RCP that blocks anything outside the org. Then it gets odd. No trail is configured, and the free tier SCP is an allowlist that blocks GuardDuty, Security Hub, Detective, Inspector, Macie and Access Analyzer entirely, while a public bucket is still a couple of clicks away. AWS is trying to make account setup frictionless while putting users on a path to a sane org setup. That comes with tough trade-offs though and I guess we'll see whether they were good trade-offs.