Permissions, Approvals, and Secret Security

The core security principle for Agents is: long-lived secrets go into the secret vault, an Agent only gets the short-lived capabilities needed to complete the current task, and high-risk operations must be approved by the user.

How permissions take effect

Heicode organizes your authorizations into a resource grant.

A grant typically includes:

• User.
• Organization.
• Task.
• Agent role.
• Resource.
• Permission scope.
• Path scope.
• Environment.
• Validity period.
• secret_ref.
• Audit information.

Users don't need to write these fields by hand, but should confirm that the summary is correct.

Principle of least privilege

Each Agent should only get the permissions it needs to complete the current task.

Example:

High-risk operations

The following operations require approval by default:

• Production deployment.
• Production database read/write.
• Access to production secrets.
• Creating, deleting, or scaling cloud resources.
• Merging to the main branch.
• Bulk file deletion.
• Sending sensitive data externally.
• Large model budget consumption.

What you see during approval

The approval dialog shows:

• Operation type.
• Requesting Agent.
• Target resource.
• Risk level.
• Short-lived credential TTL.

Target environment, expected impact, budget impact, and rollback availability may be shown depending on the specific approval scenario — these fields aren't guaranteed to appear every time.

What approving means

Approving only means allowing this particular operation.

After approval:

• The platform derives a short-lived credential.
• The credential is only valid within its TTL.
• The operation is written to the audit log.
• The Agent does not get a long-lived secret.

What rejecting means

After rejecting:

• The high-risk operation does not execute.
• The task may move into a blocked state.
• The Agent can offer an alternative approach.
• You can adjust resources or permissions and re-initiate.

The secret vault

The secret vault is used to store long-lived credentials.

Includes:

• Git tokens.
• SSH keys.
• Cloud access keys.
• Database passwords.
• Deployment credentials.
• Model provider API keys.

Secrets should never appear in:

• Git.
• Markdown.
• Frontend responses.
• Screenshots.
• Ordinary logs.
• Agent memory.
• Chat content.

secret_ref

The Heicode database only stores secret references, never plaintext secrets.

Example format:

openbao://<vault>/secrets/users-<UserId>-bindings-<scope>-resources-<Id>

This is not a plaintext secret. It just lets the backend locate the corresponding credential once approvals and permissions are satisfied.

Credential lifecycle

• Long-lived credentials go into the secret vault.
• Sub-agents only get short-lived credentials.
• Short-lived credentials expire once their TTL passes.
• Credentials that are no longer needed should be revoked once a task stops.
• Once a resource grant is deleted, new tasks can no longer use that credential.

Secret handling after account deactivation

• Once a resource grant is deleted, an account is deactivated, an organization is closed, or a subscription is terminated, available credentials immediately stop being usable for new tasks.
• Recoverable raw secret material in the production secret store is deleted or made unrecoverable within 30 days of deactivation.
• Retention policy for encrypted backups or disaster-recovery copies follows the platform's security terms.
• Where legal requirements, security incident investigations, anti-fraud measures, billing disputes, or enterprise agreements specify otherwise, those requirements govern.

Security recommendations for users

• Don't share accounts.
• Don't paste secrets into chat.
• Don't commit .env files to Git.
• Start with read-only access for resources you're unsure about.
• Always review production operations carefully before approving.
• Revoke permissions immediately when a member leaves.
• Rotate secrets immediately if you suspect a leak.