At work we kept finding the same miss. Product engineering wired Cursor to GitHub with a PAT in the laptop MCP config. CI ran Claude Code or an internal AppSec agent with GH_TOKEN or AWS keys in the job env. The agent could open a PR or touch S3. Sandbox looked fine. Then a tool dumped env, a log printed the secret, or a prompt-injected step ran printenv. The secret was already inside. The sandbox did not save us.

The fix is not "use OIDC in the deploy job." We already do that. The fix is a visible call path with three named pieces:

1. Agent. Cursor, Claude Code, Copilot Chat with MCP, or an internal AppSec agent in CI. Decides. Sends tools/call. No durable secret in its env.
2. Broker. Separate service. Company remote MCP on ECS / Cloud Run / Kubernetes, GitHub's remote MCP (https://api.githubcopilot.com/mcp/), or an egress / tool gateway such as agentgateway. Secrets live on the MCP task role, server env, or IRSA. Not on the laptop. Not in the agent job env.
3. Upstream. Real api.github.com or AWS API call leaves from the broker. Agent only ever sees tool args and tool results.

Related:

• Eradicate long-lived tokens
• MCP security gateways / cMCP
• You cannot deny every tool and still ship
• MicroVM runners vs supply chain

I already know how to sign containers. Key-based Cosign, keyless OIDC, AWS Signer + Notation without public Rekor. That still applies when the artifact is a model directory. What changed is the shape of the thing I hash.

So here we sign a model directory the same way: OpenSSF / Sigstore model-signing on a small pack, flip one weight byte and watch verify fail, then do the same in GitHub Actions.

Related container posts:

• Sign container images with Cosign (key-based)
• Cosign keyless signing with GitHub Actions OIDC
• AWS Signer + Notation (no public Rekor)

Product wants the patch before standup. Security wants a gateway that can say no. I have sat between them. Both are right until someone makes it one dial.

Deny every tool and the agent is a chatbot. I have watched engineers stop waiting. They open the IDE on the laptop, shell still on, kubeconfig still in the environment, and they ship from there. Your deny rate looks perfect. Nobody complains. That quiet is the part that gets me. The control did not win. The work left.

Same argument without the table. Let the everyday work through. Fail closed on the three that can ruin your week. Any override dies on a clock. And go find the agent that never hits the gate.

Allow the shell because the tests will not run, and you handed a confused deputy a production write. I already wrote that one up: when your bot becomes the payload. This is the deal I will defend when both sides are in the room.

You cannot deny every tool and still ship. Sort them by what they can break. Shell, secrets, and prod write fail closed. Read stays. A write that can only touch the PR branch stays. Take those away and you do not have a PR agent. You have a linter with opinions.

You ship an outer agent that plans. It spawns a "helpful" inner agent to dig, summarize, or call tools. Product demo looks clean. Trust model does not: classic confused deputy, just with LLMs.

The inner agent is often the one with broader tools, longer memory, or the system prompt that names secrets and schemas. Untrusted content does not need to jailbreak the outer model. It only needs to steer the inner one into echoing what it already knows, or calling a tool the outer agent would never have been allowed to call.

Your nested helper can become the payload. Prompt leak. Tool/schema leak. Same family of failure as approving an MCP server once and hoping every later tools/call is fine (MCP gateways).

Most access request "systems" are a scavenger hunt. Ticket portal for some tools. Slack DM for others. A spreadsheet for the weird ones. Someone with admin rights eventually clicks Approve in a console you do not have. The requester waits. The approver forgets. Onboarding docs live somewhere else.

The worst option is the DM. Access granted in a private DM leaves almost no trail. No clear record of when it was asked for, why it was needed, or who said yes. That is a time bomb for offboarding, incident response, compliance, and the 2am question: who has maintain on that repo?

The fix is not a prettier portal. Treat access request as a product lifecycle: catalog → route → grant → onboard. Put that lifecycle where the team already works. For a lot of orgs that is Slack. For eng teams living in GitHub, Issues can be the same product with a different skin.

AWS shipped GuardDuty AI Protection as GA in mid-July 2026. If you already run Bedrock or SageMaker AI and GuardDuty, this is the protection plan that finally looks at model invocation data events instead of only management-plane noise.

It is not "AI security done." It is a specific data-source plan with three finding types. Know what it watches, how to turn it on, and what to do when Low severity findings show up. Then know what it will never see.

Teams buy Firecracker-/Kata-backed runners (or DIY) and talk like the CI supply chain problem is closed. Hardware isolation. Fresh VM per job. Tear it down. The vendor deck lands. The budget conversation moves on.

A microVM protects your host from the job. You still have to protect the job from the supply chain.

Your engineering, infra, or security team is wiring agents to tools inside real environments: GitHub, Stripe, Slack, cloud APIs, filesystem servers, whatever the agent needs to act. Same session. Fine.

The quieter question is MCP gateway security: once those tools are reachable, who is actually allowed to say no before the upstream runs?

An MCP security gateway sits between the agent client and upstream MCP servers. It evaluates each tools/call against policy (allow or deny), keeps an audit trail, and optionally attests that path in a TEE. Raw MCP is the protocol and the catalog. The gateway is the control plane that can refuse a specific call before credentials, files, or APIs get touched.

That is different from a dumb reverse proxy that only terminates TLS or multiplexes routes. Auth at the door is not authz on the tool. Approving an MCP server once is not the same as deciding whether read_file on .env should ever leave the client.

I used to treat Vault like a snowflake appliance: click init, paste root token, vault write policies by hand, openssl for TLS, Terraform manifests for backups. That series still lives on this blog. Production taught a sharper split.

Ask an engineering or infrastructure team what is happening inside their CI/CD pipeline at runtime. The answer is usually a blank stare. Artifact signing, SBOMs, and locked Actions deps matured. Runtime insight into the job itself lagged behind.

The image signature said yes. Provenance said GitHub Actions on main. The image still shipped with a build that opened the wrong sockets and ran a binary nobody named in the workflow. That is not a signing-tool bug. That is a missing link in the chain of trust.

If you are still using classic GitHub PATs in your environments "just for pulling, read or packaging," you are not being pragmatic. You are accepting forever access as normal. That is a culture problem. Tooling only follows.

Publish returns ack. Consumer never sees the message. Restart a pod and a stuck queue suddenly drains. Realtime join works on one pod; another user never sees it. Websocket adapter events vanish depending on which replica you hit. Same cluster. Same Service DNS. Different JetStream stores. That is the smell.

Do you even know the supply chain risk your Helm charts carry? I bet you don't.

best bet, you are still not rotating your DB passwords and tokens across your infra, but if the software integrations you use, has a stable passwordless option, i think you shouldnt keep a static credentials option then?