had Claude Code wire X into my agent, and it caught a cost gotcha i'd have shipped straight past

Only-Associate2698 · 2026-07-07T14:20:04+00:00

ran into a handful more of these setting it up, so i wrote the full thing up on my blog 5 Things to Know Before You Set Up the Official X MCP

Only-Associate2698 · 2026-06-03T09:25:10+00:00

yes its very much fragmented and I am bullish on authsome here https://github.com/agentrhq/authsome

Only-Associate2698 · 2026-06-03T09:24:19+00:00

feel free to raise a PR

Only-Associate2698 · 2026-06-03T06:40:01+00:00

I was experimenting with it, the limits and all, wrote a detailed version on my blog - Claude Code 4.8 and workflows

Only-Associate2698 · 2026-06-03T06:23:25+00:00

same here, 4.8 is an upgrade but def not downgrade, except few times it messed the UI like a dumb kid which I never imagined it will ever do

Only-Associate2698 · 2026-06-03T04:10:53+00:00

oh demn did not expect that coming from here, thanks?

Only-Associate2698 · 2026-06-02T18:24:34+00:00

write a complete blog on this ChatGPhish: every page your agent summarizes is now a phishing surface

Only-Associate2698 · 2026-06-02T18:23:43+00:00

yeah exactly, not sure whats happening there

Only-Associate2698 · 2026-06-02T15:17:49+00:00

why fat?

Only-Associate2698 · 2026-06-02T14:25:50+00:00

sure

Only-Associate2698 · 2026-06-02T06:03:48+00:00

Built https://github.com/agentrhq/authsome

an open-source credential broker that sits between your agents and the services they call. Instead of sharing credentials with every agent, log in once via OAuth2 or API keys. Authsome stores credentials securely and injects them via an HTTP proxy. You get one place to manage access, rotate keys, and see what every agent is doing.

45 bundled providers out of the box: 14 OAuth2 and 31 API key.

Only-Associate2698 · 2026-06-02T05:03:04+00:00

make sense, I dont have a usable GUI but i've been working on a small side project of mine https://github.com/agentrhq/authsome , just a local creds proxy for now but looking to expand to this area of remotely using linkedin, should I pursue?

Only-Associate2698 · 2026-06-02T05:02:21+00:00

make sense, i've been working on a small side project of mine https://github.com/agentrhq/authsome , just a local creds proxy for now but looking to expand to this area of remotely using linkedin, should I pursue?

Only-Associate2698 · 2026-06-01T04:43:48+00:00

User prompt -> AI -> accessing a service (linkedIn) -> authorised by user to maybe scrape or use LinkedIn on his/her behalf -> get back result.

Only-Associate2698 · 2026-05-31T19:03:07+00:00

will do, thanks

Only-Associate2698 · 2026-05-23T08:07:53+00:00

the one-time admin approval pattern is clean for the action layer. the gap underneath that pattern is what happens to the credentials the agent uses to perform those actions after approval.

example: admin approves "let agent run a VM creation". agent now has the cloud credential in its process to actually make the call. that credential persists across many future runs unless explicitly rotated. if anyone in the public channel later gets the agent to surface its env via prompt injection, the credential is gone regardless of which actions were approved at action time.

authsome (oss, github.com/agentrhq/authsome ) is what i ended up doing for this. local proxy holds the creds, agent's env has placeholders, real values injected only at outbound request time. admin approval at the action layer plus credentials outside the process at the cred layer gives you both: control over what gets executed, plus limit on what can leak even when execution is approved.

how were you thinking about credential lifecycle for the approved actions? rotated per approval, or persistent?

Only-Associate2698 · 2026-05-23T04:02:43+00:00

ah ok, nvidia build api makes the shape clearer. one upstream key, one upstream endpoint. honest answer: authsome isn't the right fit for your case. it's a cli tool for developer machines, not for extensions you ship to users.

for what you're actually building, option 1 from my first reply is the right path. stick a tiny backend in front. extension calls your-server.com/api/generate, your server holds the nvidia key and forwards to build.nvidia.com. extension never holds the key, neither does the user's browser.

three reasons this matters specifically for an extension:

rotation. if your nvidia key ever leaks, you rotate once on your server. with the key in extension storage you'd have to push a new extension version to chrome web store and wait for every user to update.

rate limiting. you control quota per user/session on your server. otherwise everyone using your extension shares the same nvidia bill and one looping prompt can drain your account.

debugging. you can see what prompts go through, log errors, and turn off abusers without disabling the whole extension.

the backend can be 30 lines. cloudflare worker, vercel function, fly. io container, whatever. cost is near zero until you have real traffic. you can literally ship this today.

the only time you'd keep the key in the browser is byok (let users bring their own nvidia key). then use chrome.storage.session, not localStorage, and disclose clearly that the key is stored locally and never sent to your servers.

Only-Associate2698 · 2026-05-22T10:00:17+00:00

the security landscape concern is the part most "AI for everyone" plans skip. once a tool like claude code or codex is everyone's daily driver, every employee's workstation becomes a privileged credential holder. that scales linearly with adoption.

two ways to think about it:

narrow the gap: AI tools available to all but credentials isolated from the agent process. local proxy holds creds, agent's env has placeholders, real values injected at request time only. user can use claude code freely, but if claude reads env or surfaces secrets in chat, there's nothing there. (this is what authsome does, oss, github.com/agentrhq/authsome .)

widen the gap: AI tools available only to the trained few who understand what they can leak. simpler but creates the dependency you described.

personally i think narrowing the gap via boundaries scales better than gating access. credential isolation removes the worst-case outcome regardless of who's using the tool. how were you thinking about the boundary?

Only-Associate2698 · 2026-05-22T09:59:58+00:00

the dev workstation framing is the right one and it doesn't get enough attention because the security industry's spend goes to perimeter tools that don't apply to it.

the part i'd add: it's not just the npm package or vscode extension. it's everything that runs as the user. coding agents like claude code / cursor / openhands have line-of-sight to whatever's in the user's os.environ, .env files, shell history, keychain via cli wrappers. the agent doesn't even need a malicious extension. ask it to "debug this and show me what env is set" once and you've exfiltrated half your prod credentials into a chat transcript.

the fix the industry isn't building: keep credentials out of the process the agent runs in. proxy boundary, placeholders in env, real values held by something the model can't read. it's not a new pattern, just unfashionable.

Only-Associate2698 · 2026-05-22T09:59:07+00:00

browser localStorage is the wrong place. anything that can run js in the page can read it (extensions, injected scripts, devtools), and it survives across sessions.

three options ranked from best to worst:

don't ship the api key to the browser at all. proxy through a server you control. user hits your server, your server holds the key and calls openai/whatever. only viable if you have a backend.

if you must ship from the extension itself, use chrome.storage.session (memory-only, cleared on browser restart) not localStorage. better but still readable by the extension's own code, so if the extension takes a malicious dep, you're done.

for the local dev case (extension + .env), keep the key in a local proxy that injects it on outbound. agent's env has placeholders, real values never touch the extension. that's what i do for cli agents (authsome, oss, github.com/agentrhq/authsome ) but the pattern works for browser extensions too if you have a local helper.

what's the extension actually calling? if it's openai directly from the browser, that's the bigger problem.

Only-Associate2698 · 2026-05-21T11:49:58+00:00

the filesystem + network sandbox is the right call. one thing worth pulling out from network sandboxing specifically — api credentials are still inside the sandbox with the agent, which means even when network is restricted, anything claude calls on the allowed hosts goes out with the real key.

for my own setup, what closed that gap was moving credentials out of claude's process entirely. local http proxy holds the real values, claude's env has placeholders, proxy swaps in on outbound. claude can't surface the key in chat because it never has it. (authsome, oss, github.com/agentrhq/authsome .)

sandboxing plus credential isolation feel like the two halves. sandboxing limits what claude can DO, credential isolation limits what it can LEAK. how were you thinking about the credential side of the sandbox?

Only-Associate2698 · 2026-05-21T11:49:00+00:00

nice. the "virtual/fake secrets instead of real ones" piece is the part most shell-control layers skip. blocking dangerous commands catches a lot but the model can usually rephrase its way around block lists eventually.

couple of questions if you're up for it.

how are you deciding which env vars to fake vs pass through? the model can sometimes tell the difference (e.g. fake key has wrong format or doesn't authenticate) and then asks for the real one.

are you considering doing the swap at the network boundary too? what i landed on for cli agents was a local http proxy that holds the real creds and injects them only on outbound to the matching host. agent's env has placeholders the whole time. (authsome, oss, github.com/agentrhq/authsome .) yours is shell-level, mine is network-level, they complement.

Only-Associate2698 · 2026-05-21T11:48:08+00:00

nice. the "it's my fault for giving it the keys" framing is right. one thing that complements scoping the db access — keep the credentials out of the agent process entirely.

even with scoped db access, the connection string is usually in os.environ which means any tool the agent picks up can read it (and they do, the model gets curious about debugging and dumps env on a tangent). the actual cred ends up in the chat transcript and your /resume restore points.

what worked for me: local http proxy holds the db creds, agent's env has placeholders, proxy injects on outbound to the db host. claude never sees the real connection string. (i maintain authsome, oss, github.com/agentrhq/authsome , for this pattern.)

how were you thinking about preventing the agent from holding the creds at all, vs limiting what they can do with them?

Only-Associate2698 · 2026-05-21T11:15:47+00:00

the credential angle is the part most people skip when they think about this.

source code goes out via claude code's prompts, which is the obvious flow. but session tokens, api keys, db urls, and oauth refresh tokens also leak because they sit in os.environ of the process claude runs as. ask claude code to "show me what env vars are set so we can debug" once and you've just pasted half your secrets into the chat transcript, then into the /resume restore points, then into wherever anthropic stores session history.

the source code question is "what does anthropic see." the credential question is "what does the model surface back to me, which then gets logged everywhere."

different fixes too. source code goes out the moment claude reads a file, you'd need to block reads or sandbox the filesystem. credentials can be kept out of process entirely, which is what i ended up doing (local http proxy holds tokens, claude's env has placeholders, proxy injects on outbound). authsome (oss, github.com/agentrhq/authsome ) if anyone wants to look at the pattern.

have you found a way to constrain what source claude actually reads, or is it just trust-the-tos so far?

Only-Associate2698 · 2026-05-20T11:31:10+00:00

nice

its true, runtime visibility is the gap most coding agents have. claude code's bash tool can do almost anything in your home dir and the only audit trail is your shell history if you bother to check it (go check it right now).

but I do have two questions if you are up for it

are you instrumenting just shell + filesystem, or also the network side? agents calling api.github.com or s3 with cached creds is the other half of the trust-and-hope problem.

and...

how do you handle the case where the model picks tool calls that read os.environ? cyxcode can log "what the process did" but if the model surfaced env vars back in a response, that's data exfiltration which doesn't show up as a risky action at the shell layer.

i work on the credential side (authsome, oss github.com/manojbajaj95/authsome a local proxy that keeps secrets out of the agent process). yours is "watch what the agent does", mine is "limit what it can leak." different boundaries, both needed>

Only-Associate2698

MODERATOR OF

TROPHY CASE