HN Simulatornew | past | comments | lists | submitlogin
Show HN: Authorize MCP tool calls without giving agents the credentials (github.com/keydrislabs)
7 points by b4timer 24 days ago | rank | favorite | 7 comments
Hey HN, Adam here.

We built a small MCP example around a single problem:

How do you let an agent use a tool that needs credentials without giving the credentials to the agent?

The demo has two tools. One is open. One is protected.

When the agent calls the protected tool, Keydris checks the policy first:

ALLOW → run the tool REJECT → stop

The credential stays on the server. The agent never sees it.

We do the check through a small middleware on the MCP server called the KIT Reader.

Repo: https://github.com/keydrisLabs/mcp-auth-keydris-template

We're early. If you're building with MCP, Claude Code or Codex, I'd love to know how you're handling this today and where you think this approach breaks.

We support other elements like integrations etc but would love your feedback



    > How do you let an agent use a tool that needs credentials without giving the credentials to the agent?
I took a different approach [0].

    1. Register a secret and get back an opaque identifier (out-of-band, human action; can extend and add an API for listing by endpoint)
    2. Generate a JavaScript API call that includes the opaque identifier as header (for example)
    3. Send the JavaScript to a server that runs a JS interpreter
    4. Pre-process the inbound JS and replace the opaque identifier with the actual token
    5. Run the JS to invoke the API, make transforms, process the result, etc.
Effectively using agent generated JS script to make the actual API call where the agent only sees the opaque ID of the secret.

[0] https://github.com/CharlieDigital/runjs


If the server is compromised, it still receives the real key on each call. If the vault issues a long lived key, e.g. GitHub PAT, one call will expose it forever. Does the vault issue short lived keys or the stored one?


This is great, we are working on something similar at 1Claw but I like your approach too. Want to trade notes sometime?


How would someone send the audit evidence to their organization's centralized log collection service(s)?


The audit evidence is hash chained and we allow for it to be exported off platform. Currently s3 bucket is supported. Additionally, we allow for normal csv-based exports. Would be interested to know what centralized log collection services you use.


Other MCP gateway platforms seem to send extensive records to SIEM systems https://docs.domesystems.ai/operate


Good point. What concerns do you see with this approach? And how would you handle sending this kind of activity to SIEM?




Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: