Local vault + MCP secret broker

Run AI coding agents without exposing real secrets.

AgentSecure starts with agentsecure start: import .env into a local vault, rewrite files with placeholders like ${API_KEY}, generate AGENTS.md, and let MCP tools resolve real secrets only for approved API calls.

Open console

Community version

agents see placeholders real values stay local approved destinations only

Vault + MCP broker graph brokering secrets

acme-api - agentsecure start local vault

dev@laptop acme-api % agentsecure start
found .env with 4 secret-like values
created local vault: ~/.agentsecure/vault
backup written: .env.agentsecure.bak

.env rewritten with safe placeholders:
OPENAI_API_KEY=${OPENAI_API_KEY}
STRIPE_SECRET_KEY=${STRIPE_SECRET_KEY}

generated AGENTS.md with secret-use guidance

Codex MCP:
codex mcp add agentsecure -- agentsecure --config ./agentsecure.json mcp serve

0 exposed values 4 vault entries 1 trust layer

Something big is on the way

Agents will be able to ask the right team agent.

A frontend agent can ask a backend team agent about an API change, with AgentSecure routing the question through identity, policy, approval, and audit. That only works when the product sits between the agents.

Frontend agent AgentSecure Backend team agent

Why this exists

The gap

Companies are adding agents faster than they can govern them.

Local agents, review agents, security agents, CI agents, and documentation agents all need to coordinate. Direct prompts and ad hoc tool calls do not give teams identity, ownership, approvals, or audit.

01 Who is acting?

Each agent gets a durable identity, owner, team, trust level, and allowed scopes.

02 Who can it ask?

Messages go through a controlled inbox instead of raw agent-to-agent prompting.

03 Who approves?

Sensitive actions route to humans, teams, or approved agents before execution.

04 What happened?

Messages, denials, approvals, and adapter actions are written to audit.

Product capability

AgentSecure is not an agent chat app. It is the control plane between agents.

Agents interact through AgentSecure tools: check messages, ask owners, request approvals, resolve denials, comment on resources, and inspect audit context. Policy decides whether the action is allowed, denied, or escalated to a human.

Read the brief

What agents can do

Ask, approve, hand off, and act through governed tools.

AgentSecure gives agents a small set of explicit actions. Every request has an actor, resource, policy decision, next step, and audit event.

Blocked agents get useful next steps. Instead of retrying a denied action, the agent can request approval or ask the owner.

Agent AgentSecure Mesh Human / tool / agent

message

Ask another agent

send_message routes questions through policy and a controlled inbox.

approval

Request a decision

request_approval sends risky actions to the right human or team.

adapter

Act on resources

comment_on_resource maps generic actions to GitHub, Jira, CI, or local tools.

Example flow

A frontend agent needs an API change. AgentSecure controls the path.

Switch between the question, approval request, and policy denial states. The terminal shows what the agent sees.

$ agentsecure send-message backend-agent \
  --type question \
  --resource repo:company/app:path:src/api/users.ts \
  --subject "Can frontend rename fullName to name?"

[ok] policy allowed frontend-agent -> backend-agent
[ok] delivered to backend-agent inbox
[ok] audit event: message_sent

View GitHub

Policy engine

Every agent action is allowed, denied, or escalated.

Policy controls who can message, who can approve, which resources are in scope, which tools are allowed, and when a human must decide. Denials include a concrete allowed next step.

policy denial:
  actor: frontend-agent
  action: change_api_contract
  resource: repo:company/api:path:src/users.ts
  reason: platform team approval required
  next_step: request_approval(change_api_contract)

Identity

Policies target named agents, teams, trust levels, repos, tools, and environments.

Human control

Sensitive actions become approval requests with resource context and reason.

Next steps

Denied agents receive the exact tool call that can move the work forward safely.

Audit + visibility

Teams can see what agents asked, who approved, and what changed.

AgentSecure records meaningful events: messages, reads, replies, approvals, denials, human decisions, adapter actions, and resource touches. Secrets stay local; decision metadata stays searchable.

actor frontend-agent requested change_api_contract

approver platform team approved with migration requirement

audit full decision chain message, approval, resource, and adapter event

Chat tools move prompts CI tools run jobs AgentSecure governs agent identity, communication, approvals, policy, audit, and adapters Agents keep using normal coding tools

Product surfaces

Local developers, team admins, and ops use the same mesh.

Start with a local daemon and Desktop approvals, then add Console policy, team audit, adapters, and deployment controls.

runtime

AgentSecure core

Daemon, identity, inbox, policy, approvals, audit, MCP tools, and local broker.

See message flow

desktop

ShellFrameDesktop

Local approval center, notifications, audit timeline, policy editor, and daemon control.

See audit path

console

AgentSecureConsole

Workspace registry, central policy, approval dashboard, audit explorer, and adapter setup.

Review trust layer

Start local, govern teams later

Put AgentSecure between agents, humans, and tools.

Open console Request team access