Appearance

Agents often need API keys, passwords, and other secrets to do their work, such as calling external APIs, logging into websites, or deploying apps that connect to services. Frona gives you full control over which agents can access which secrets, and for how long.

How it works ​

When an agent needs a credential it doesn't have access to, here's what happens:

  1. The agent requests access. You see a notification in the chat explaining what it needs and why.
  2. You review the request. Check what secret the agent wants and what it plans to do with it.
  3. You approve or deny. If you approve, you choose how long the grant lasts:
    • Once. Single use, no persistent access.
    • Hours. Access expires after a set number of hours.
    • Days. Access expires after a set number of days.
    • Permanent. Access doesn't expire (can be revoked anytime).
  4. The agent gets the credential. It's delivered as environment variables, never exposed in the conversation.

Agents never access secrets without your explicit permission.

Where credentials come from ​

Local credentials ​

Store credentials directly in Frona through the platform interface. Local credentials are encrypted at rest with AES-256-GCM and scoped to your user account.

Binding modes ​

When you grant a credential to an agent or an MCP server, you choose how the values are exposed as environment variables:

ModeWhat it does
Single fieldOne env var maps to one specific field of the vault item (e.g., GITHUB_TOKEN → the password field)
All fieldsEvery field becomes an env var with its standard name (USERNAME, PASSWORD, URL, …)
PrefixEvery field becomes an env var with a custom prefix (GH_USERNAME, GH_PASSWORD, GH_URL)

Use single field when the consumer expects exactly one value with a known name. Use all fields when it expects the standard set. Use prefix when multiple bindings would otherwise collide (two GitHub accounts, primary and CI). MCP servers in particular often use prefix bindings.

Types you can store:

  • API keys for external services (OpenAI, GitHub, Stripe, etc.)
  • Username/password pairs for website logins
  • Browser profiles that preserve login sessions for automated browsing

Vault providers ​

Connect Frona to your existing password manager so agents can access secrets from your vault:

  • 1Password
  • Bitwarden (including self-hosted)
  • HashiCorp Vault
  • KeePass

See Connecting Your Password Manager for setup.

Managing grants ​

Review and manage all active grants in the vault management interface:

  • See which agents have access to which secrets
  • See when each grant expires
  • Revoke any grant immediately. Takes effect instantly.

Expired grants are automatically cleaned up. Agents will need to request access again.

Audit trail ​

Every credential access is logged:

  • Which agent accessed the credential
  • Which conversation it happened in
  • What the agent was looking for and why
  • When the access occurred

This gives you a complete audit trail for security reviews.

Tips ​

  • Start with short grants. Use "once" or "hours" until you trust the workflow, then extend to longer durations.
  • Use vault providers when possible. They avoid duplicating secrets and integrate with your existing security infrastructure.
  • Review grants periodically. Check the vault management interface for grants that are no longer needed.
  • Permanent grants are convenient but risky. Only use them for credentials an agent needs regularly and that you trust it with.

Security details ​

  • All local credential values are encrypted at rest with AES-256-GCM
  • Encryption key is derived from FRONA_AUTH_ENCRYPTION_SECRET
  • Credentials are scoped to your user account. Other users cannot access them.
  • Credential values are never logged or exposed in API responses
  • Vault provider configurations are also stored encrypted

Next steps ​

Frona AI