Security

Your code never leaves your machine.

gyve briefs your agents; it doesn't run them or read your repository. What crosses the wire is a tool call with a key, and every one of them is on the record.

Stays on your machine
  • Your code and files
  • Your terminal and the commands run in it
  • Your environment and its secrets
  • The agent itself, wherever it runs
tools/call over HTTPSBearer gyve_…
All gyve holds
  • Projects and which path they follow
  • Which steps are done, by whom and when
  • The notes agents leave on finished steps
  • The audit log of every call
  • Accounts, organizations, and agent keys as hashes

Agent keys

Follow a key from first call to last

Press through it. The hash below is worked out in your browser from the key it just made, the same way gyve stores it.

  1. 1Create a keyMade on the dashboard's Connect page, for one agent or one machine.
  2. 2Shown onceYou copy it now. gyve never shows it again, because it no longer has it.
  3. 3Stored as a hashOnly the SHA-256 is kept, so a leaked database holds no working keys.
  4. 4ScopedLimited to one project, the key can't reach any other, whatever the agent asks.
  5. 5RevokedOne click, and the next call that uses it is refused.
dashboard · connect

No keys yet. Press “Create a key”.

agent · tools/call
Calls with this key show up here.

Controls

What's on by default

Not settings to remember: this is how gyve runs. Single sign-on comes with Enterprise and custom roles from Business; everything else is on every plan.

Access
  • Two-factor sign-in with an authenticator app and recovery codes
  • SAML single sign-on through your identity provider, on Enterprise
  • Built-in roles, and custom ones from Business up, checked permission by permission
  • Agent keys limited to one project when that's all an agent needs
Sessions and requests
  • Sessions and invitation links stored as hashes
  • Sessions extended while active and capped at 30 days
  • Rate limits on logins, sign-ups, resets and two-factor codes
  • Cross-site requests refused, a Content-Security-Policy on every page
Visibility
  • Every agent tool call recorded in your organization's audit log
  • Who finished each step, when, and the note they left
  • A security email whenever how someone signs in changes
  • Any step can be reopened to have it done again
Scope
  • Every call is held to the key's organization
  • A scoped key can't even see that other projects exist
  • Revoked keys are refused on their next call
  • Agents don't take seats, and can't invite or change roles
Operations
  • Production refuses to start with unsafe settings
  • Two-factor secrets encrypted at rest
  • Secrets kept in a secret manager and mounted at runtime
  • One account per email address, whatever its case

For your security team

What reviewers ask

Does gyve see our code?

No. Your agent runs where it always does and works on your code there. It asks gyve for guides, steps and project state, and tells gyve which steps it finished. The notes on finished steps are written by your agent, so they hold only what it chooses to say.

How are agent keys stored?

As a SHA-256 hash and a short prefix so you can tell keys apart. The full key is shown once, when it's made, and gyve can't show it again because it doesn't have it.

Can we limit what an agent can reach?

Yes. Limit a key to one project and every call for another project is answered as if it didn't exist. Revoke a key and its next call is refused. Each key belongs to one organization and can't reach any other.

Can we see what agents did?

Every tool call is in your organization's audit log, and each finished step shows who did it, when and the note they left.

Who do we talk to for a security review?

Email hello@gyve.dev with your questionnaire or the questions your team has, and we'll take you through how gyve works.

Your next agent session starts briefed.

Start a project on a path, connect your agent with one command, and watch it build on patterns that hold up.

claude mcp add --transport http gyve https://api.gyve.dev/v1/mcp