Concepts

enoki lets a Slack user operate Google Cloud in plain language. The model turns a request into a typed, validated action; enoki runs it under that user’s own Google identity; and anything consequential waits for a human approval in the thread. This page covers the ideas that make that safe.

Two identities, never mixed

enoki runs on two separate Google identities, and keeping them apart is the whole design:

• Inference identity — the model itself (Gemini on Vertex AI) runs as enoki’s own service account, via Application Default Credentials. This identity only ever calls Vertex; it has no path to your data.
• Data-access identity — every GCP tool call runs as you, using credentials from your own Google OAuth grant. Your IAM roles are the boundary. There is no shared “bot admin” account and no god-mode.

So enoki can think without touching your cloud, and act only with exactly the permissions you already have.

The model proposes; it never authorizes

The language model’s job is to propose a tool call — never to execute a raw command. Two properties enforce this:

• Typed tools only. Every capability is a named tool with validated fields: list_bigquery_datasets(project_id), create_pubsub_topic(project_id, topic_id). There is no run_gcloud(command) or execute(sql) escape hatch. To act, the model must fill in a typed, bounded request.
• Reads run; writes wait. Read-only tools run immediately under your identity. Any write — create, delete, start, stop — pauses the run and posts an Approve / Deny button in Slack. Nothing mutates until you click.

See Guardrails for the full set of rules and Tools for every action enoki can take.

Human-in-the-loop approval

When the model calls a write tool, the agent run returns a deferred request instead of finishing. enoki stashes the paused run and renders one Approve/Deny row per pending call, so you can approve some and deny others in a single message. Approvals are single-use: a second click on an already-decided action is ignored.

Only once every pending call is decided does enoki resume the run — executing the approved calls under a freshly loaded copy of your credentials, and recording the outcome.

Zero-copy by default

enoki is built to hold no Slack data outside your own project, and as little as possible even inside it. Conversation context is short-lived: it carries a 24-hour TTL and is re-fetched live — held in memory on a single instance, or in Firestore inside your own project when enoki scales out. Channel names and file contents are never persisted; exports are handed straight back to Slack as files. The only durable state is your encrypted Google refresh token and an append-only audit record. See State & Storage for the complete inventory.

Everything is audited

Every GCP tool call enoki makes is written to a structured audit log: who ran it (Slack user + Google email), which tool, whether it was a read or a write, its arguments, and the result. Denied approvals are recorded too. See Architecture for where the trail lives.

Next: Architecture — how the pieces fit together.