certlocker @certlockerio - Twitter Profile

Pinned Tweet

3 days ago

Replacing a shared .env file with scoped MCP tokens I appreciate the time if you read all of this. I work on CertLocker so this is a product post as well. And it's fully working and out in the open. It's a devops control plane that handles secrets and tokens as well as a few other things. But today I just want to show the MCP side and get some feedback. I was talking to an agency recently about how they are using Claude and MCP agents for real client work. Reports. Scripts. SOPs. Campaign checks. Small bits of automation. They have staff and contractors working from different countries and the access side of it was the part that stood out to me. It was basically one .env file with all the useful stuff inside it. AI provider keys Client advertising tokens Search Console OAuth Webhook secrets GitHub tokens SOP repo access Then that file, or parts of it, gets passed around because people and agents need access to get the work done. I have done the same thing myself plenty of times. The problem is once you give someone the .env file they have access to everything inside it. A contractor working on Client A might also have Client B credentials. An agent checking SOPs might also be able to read webhook secrets or tokens it has no reason to access. Something gets printed into logs. Copied into chat. Pasted into another tool. Then later someone asks who accessed what and you are trying to work it out from different systems. That is the problem we have been working on with CertLocker and MCP access. Instead of giving the agent the full .env file we import each entry as its own secret. Secrets can then be grouped by client or function. Each agent gets its own identity. Each agent gets its own scoped token. The agent can ask CertLocker for one specific secret through MCP. CertLocker checks the group and scope. The request is allowed or denied. Either way it is logged. If one agent or contractor needs removed you revoke that one identity. You do not need to rotate every client credential because one person or agent had access to the same file. So the agent does not get the whole env file. It gets access to the few secrets it actually needs. The bit I am still working out is how granular the scopes should be. Too broad and you are back to the same problem. Too narrow and people will just get annoyed and start passing .env files around again. For anyone building MCP servers or using agents with contractors/staff how granular are you making the access? We also offer an on-prem model for companies who do not want secrets or credentials stored with a third party I wrote up the full workflow with screenshots here: https://t.co/5PdhtZn8zT #AI #MCP #AIAgents #Claude #ModelContextProtocol #DevOps #SecretsManagement #AIInfrastructure

certlockerio's tweet photo. Replacing a shared .env file with scoped MCP tokens

I appreciate the time if you read all of this.

I work on CertLocker so this is a product post as well. And it's fully working and out in the open. It's a devops control plane that handles secrets and tokens as well as a few other things. But today I just want to show the MCP side and get some feedback.

I was talking to an agency recently about how they are using Claude and MCP agents for real client work.

Reports.

Scripts.

SOPs.

Campaign checks.

Small bits of automation.

They have staff and contractors working from different countries and the access side of it was the part that stood out to me.

It was basically one .env file with all the useful stuff inside it.

AI provider keys

Client advertising tokens

Search Console OAuth

Webhook secrets

GitHub tokens

SOP repo access

Then that file, or parts of it, gets passed around because people and agents need access to get the work done.

I have done the same thing myself plenty of times.

The problem is once you give someone the .env file they have access to everything inside it.

A contractor working on Client A might also have Client B credentials.

An agent checking SOPs might also be able to read webhook secrets or tokens it has no reason to access.

Something gets printed into logs.

Copied into chat.

Pasted into another tool.

Then later someone asks who accessed what and you are trying to work it out from different systems.

That is the problem we have been working on with CertLocker and MCP access.

Instead of giving the agent the full .env file we import each entry as its own secret.

Secrets can then be grouped by client or function.

Each agent gets its own identity.

Each agent gets its own scoped token.

The agent can ask CertLocker for one specific secret through MCP.

CertLocker checks the group and scope.

The request is allowed or denied.

Either way it is logged.

If one agent or contractor needs removed you revoke that one identity.

You do not need to rotate every client credential because one person or agent had access to the same file.

So the agent does not get the whole env file.

It gets access to the few secrets it actually needs.

The bit I am still working out is how granular the scopes should be.

Too broad and you are back to the same problem.

Too narrow and people will just get annoyed and start passing .env files around again.

For anyone building MCP servers or using agents with contractors/staff how granular are you making the access?

We also offer an on-prem model for companies who do not want secrets or credentials stored with a third party

I wrote up the full workflow with screenshots here:

https://t.co/5PdhtZn8zT

#AI #MCP #AIAgents #Claude
#ModelContextProtocol #DevOps #SecretsManagement #AIInfrastructure

0

12

certlocker

@certlockerio

Last Seen Users on Sotwe

Trends for you

Most Popular Users