SECURITY · THE GOVERNANCE STORY
Governed by default.
Self-learning agents have a documented failure mode: give an agent memory and self-written code, trust the operator, and hope. Skadi is designed as the inversion — the design is grounded in published agent research and in the hard lessons of OpenClaw's public security record. The agent operates inside your Snowflake perimeter, under your policies, on the record.
RESTRICTED CALLER'S RIGHTS
The agent inherits the asker's limits.
Interactive requests are designed to route through Snowflake's Restricted Caller's Rights, so queries execute under the actual user's roles. Masking policies, row-access policies, and RBAC evaluate against that person — the agent literally cannot read what the asking user can't. Autonomous background runs use a narrowly scoped application role instead.
ACCESS_HISTORY
Attribution to the human, not the bot.
Every data access is auditable through Snowflake-native mechanisms — ACCESS_HISTORY and event tables — attributed to the real user who asked. Your existing audit tooling sees Skadi's work the same way it sees everyone else's.
EGRESS · DENY BY DEFAULT
No quiet phone-home.
All outbound network access is deny-by-default and must be explicitly approved by you via External Access Integrations. The current build's egress allowlist is Slack only — `api.slack.com`, `hooks.slack.com`, `files.slack.com`, `slack.com`, port 443 — and it makes no other outbound connections.
SKILLS & MEMORY AS BOUNDARY
The agent's own output is treated as untrusted.
Self-written skills and memory are an attack surface, so Skadi treats them as a security boundary: provenance on every write, sanitization, per-user isolation to prevent cross-user poisoning, and injection guardrails.
THE VERIFICATION GATE
Nothing self-written runs twice unchecked.
No skill Skadi writes becomes reusable until it passes executable verification — dry-run checks, not self-grading — and risk-tiered human approval for anything with real blast radius.
CONTROLS · AS BUILT
What you can point at.
From the app's own consumer documentation:
| INSTALL-TIME PRIVILEGES | A small, fixed privilege set, each shown to you at install; the sensitive two (warehouse management, account-usage read) are manual grants that are never taken silently. |
|---|---|
| NO EMBEDDED CREDENTIALS | No credentials in the container image; the app authenticates via Snowflake-managed identity. |
| STATE STAYS HOME | Memory, skills, sessions, and the audit log live in the app's own schema in your account, preserved across upgrades, shared with no one. |
| DATA READ = YOUR GRANT | Skadi reads data using exactly the access you grant it, and sends nothing off-account except the Slack messages you direct it to post. |
| HUMAN-APPROVED ACTIONS | Consequential actions — skill promotion, cost-anomaly warehouse suspension — sit behind explicit human approval. |
CAVEATS · READ THIS PART
What we haven't proven yet.
We'd rather you hear this from us:
- The per-user least-privilege model (Restricted Caller's Rights) is the hardest part of the build and the core of the governance story. It is designed, mapped to Snowflake primitives, and verified feasible against primary documentation — but the current demo runs single-user, under owner's rights. Designed is not demonstrated, and we won't claim otherwise.
- Skadi is pre-launch. There are no certifications to show you, so there's no badge wall on this page. When there's something audited, we'll publish it.
- Some Snowflake Cortex features Skadi uses are in preview and can change under us.
If your team's job is to poke holes in exactly this kind of design, we want you as a design partner.