initializ Policy over what agents do
Org- and workspace-level deny/allow lists over egress domains, tools, models, and channels — with hard caps on egress list size and tool count.
Governance & policy
Governance that authorizes agents — not just isolates them.
initializ makes governance a first-class pillar of running AI agents in production. Set policy once — in agent semantics like models, tools, commands, and egress — and initializ enforces it at construction, at runtime, and at the egress boundary, on agents you didn’t have to modify, with a hash-chained audit trail behind every action.
Agent task tool call requested
Admission token budgets checked
Guardrails PII, injection, content
Tool registry default-deny · scoped per agent
Auth mode per-tool decision
Egress allowlist deny-all by default
Execute constrained, recorded
platform short-lived token minted; refresh stays platform-side
user acts as the requester — attributed and scoped to them
approval pauses for a human; timeout is a denial, never an allow
Hash-chained audit every stage, every verdict — append-only
01
Policy in agent semantics Isolation protects a runtime; it does not authorize an autonomous agent. Policy expressed in agent semantics does.
Not raw cloud primitives
Per-session microVM isolation protects a runtime — it doesn’t authorize an agent that is the sole principal. Agent-semantic policy does.
Set once, follows the agent
Policy travels with the agent across clouds and frameworks — one definition, enforced everywhere it runs.
02
Three enforcement points Governance applied without changing a line of agent code.
Construction
Every agent skill is risk-scored at build; a skill exceeding your threshold — or a forbidden configuration — fails the build with a precise message, not a crash-loop in production.
Runtime
Policies compile to a per-workspace runtime policy delivered on publish; agents enforce it fail-closed — a malformed policy stops the agent, it doesn’t run unprotected.
Egress boundary
Deny-all egress with an explicit allowlist, enforced by NetworkPolicy and in-process.
03
Identity, credentials & delegation Agents don’t hold long-lived MCP credentials — the platform brokers scoped, expiring tokens.
Platform-brokered credentials
Agents never hold long-lived MCP credentials. The platform holds the credential and hands the agent a short-lived token on request — the refresh credential stays platform-side.
Per-identity credential vault
Consented credentials are stored encrypted and isolated per identity — one agent’s credentials can never be reached from another’s context.
Act on behalf of the user
For writes, an agent can act as the requesting person, not a shared identity — attributed to, and scoped by, the actual user who asked.
Zero-config MCP authentication
Connect an MCP server with just its URL — OAuth authorization-server discovery and dynamic client registration are automatic (RFC 9728 / 8414 / 7591).
Step-up authentication
Sensitive actions can demand stronger re-authentication before proceeding — a standards-based challenge, not a custom prompt.
Enterprise OIDC inbound
Agents authenticate callers against your enterprise identity provider — provider-agnostic OIDC.
04
Governed execution Agents run real tools under enforced constraints — not raw shell, not sandbox-and-hope.
Governed tool registry
Tools are admitted into a central registry and scoped per agent — adding a tool is an admission decision, not an agent-side free-for-all. Default-deny: everything not explicitly allowed is denied.
Granular MCP control
Access is controlled per operation and per resource — one agent scoped to one Confluence space, another to a different space, enforced at the source.
Hardened binary execution
Agents run real tools — kubectl, psql, git — through a single execution path with layered controls: binary allowlists, argument validation, filesystem confinement. Not raw shell.
Enforced deny, not advisory
A blocked tool call never reaches execution — enforcement sits ahead of the call, not in a log after it. Every tool resolves to a live health state, so agents degrade gracefully.
05
Approvals & step-up Humans in the loop where it matters — and denial as the default when they don’t answer.
Pause for a human
Any tool can require human approval: the agent pauses, an approver approves or rejects out-of-band, and the call resumes or fails.
Timeouts fail closed
An unanswered approval times out to a safe denial — never a silent allow. Every transition is recorded.
Per-tool authentication choice
Each tool can be platform-authenticated, user-authenticated, or gated behind human approval — chosen per tool, enforced by the runtime.
06
At par with the hyperscaler — in your cluster All shipped today. Capabilities AWS Bedrock AgentCore also provides — with the initializ version running inside your own boundary.
| Capability | initializ (shipped) | AgentCore analog |
|---|---|---|
| Per-user credential vault + isolation | Encrypted grants, isolated per identity | Token Vault (per-user) |
| Brokered short-lived tokens | Scoped expiring tokens; refresh stays platform-side | Workload access tokens |
| Act on behalf of the user | Delegated writes attributed to the requester | 3LO on-behalf-of |
| Granular tool + resource scoping | Registry + per-operation, per-space grants | Gateway target scoping |
| Human approval gates | Pause-and-resume, fail-closed, audited | Approval patterns |
| Tamper-evident audit | Hash-chained append-only log | Audit logging |
| Inbound identity | OIDC caller authentication | Inbound Auth (Cognito/OIDC) |
| MCP / outbound auth | Zero-config OAuth discovery + DCR, encrypted store | Outbound Auth providers |
| Default-deny egress | Allowlist-based outbound control | Gateway egress controls |
| Build & policy gating | Risk-scored build gate + policy-as-config | Guardrails / policy |
Parity, plus residency: the same identity, credential, and governance controls — running inside your own cluster instead of a vendor-managed account.
07
Typed guardrails overlay Enforced by the runtime on top of each agent’s own config.
Tighten-only
An overlay can force protections ON on top of each agent’s own config — never loosen them.
Detection built in
PII (mask or block per category), prompt-injection and jailbreak detection, content moderation with per-category thresholds, NSFW, and hallucination checks with source-count requirements.
Your rules too
URL filtering, custom regex and keyword rules, and human-approval gates.
08
Token budgets & admission control Budgets that actually stop overruns — at task admission, not on the invoice.
Quotas at three scopes
Hourly, daily, and monthly token budgets at org, workspace, and agent level.
Denied at admission
Exhausted budgets deny new tasks at admission — not on the invoice.
Every denial audited
Each admission denial is an auditable event, attributable to the quota that fired.
09
RBAC, audit & security operations Compliance you can verify, not just trust.
RBAC throughout
Org admins and members plus per-workspace roles, keyed to your identity provider — provider-agnostic OIDC (Okta verified). No proprietary auth lock-in.
Hash-chained, append-only
Every action lands in an append-only audit trail; per-record hash-chaining makes tampering evident.
Security Events
The full audit stream — filterable, grouped by execution, with posture rollups: top denials, quota hits, rule attribution.
10
Governance questions
What does governance mean for AI agents?
Governance is the discipline of controlling what agents are allowed to do in production — their identities, tool permissions, model access, and data movement — and proving it with audit. initializ enforces this with policy expressed in agent semantics, RBAC, and hash-chained audit trails.
Do I have to change my agent code to govern it?
No. initializ enforces policy in the platform itself — a pre-build policy gate at construction, a per-workspace runtime policy enforced fail-closed, and deny-all egress at the network boundary — so governance is applied without requiring changes to customer agent code.
What is a hash-chained audit trail?
An append-only log where each record is cryptographically chained to the one before it, so any tampering is evident. initializ writes one for every agent action — a property your security and compliance teams can verify, not just trust.
How is agent-semantic policy different from cloud IAM?
Cloud IAM governs cloud primitives — roles, resources, API calls. initializ expresses policy in agent semantics: models, tools, commands, egress, and channels. That’s the layer where an autonomous agent actually needs to be authorized.
Who can change policy inside initializ?
Access is governed by RBAC, authenticated against your own OIDC provider — so policy changes follow the same enterprise identity and role controls as the rest of your stack.
What happens when a token budget runs out?
New tasks are denied at admission. Hourly, daily, and monthly quotas apply at org, workspace, and agent scope, and every denial is an auditable event — overruns stop at admission, not on the invoice.
How do agents authenticate to MCP servers?
Through the platform. Connect an MCP server with just its URL — OAuth discovery and dynamic client registration are automatic — and agents receive short-lived, scoped tokens on request while the refresh credential stays platform-side. Agents never hold long-lived MCP credentials, and each tool can be platform-authenticated, user-authenticated, or gated behind human approval.
What happens when a tool call needs human approval?
The agent pauses. An approver approves or rejects out-of-band, and the call resumes or fails accordingly. Approvals time out to a safe denial — never a silent allow — and every transition is recorded in the audit trail.
Put policy behind every agent.
Agent-semantic policy, RBAC, and tamper-evident audit — in your cluster, on your terms.