Governance layers
- Action policies decide whether proposed operations are denied, auto-approved, or routed to human approval.
- Memory review keeps durable context changes explicit.
- Source configuration changes are modeled as admin-gated actions.
- Audit records tie work to org, run, entity, actor, role, backend, and timestamps.
- Feature gates turn advanced controls on per org or deployment.
Feature gates
OpenNeko can resolve feature availability from org features, OPENNEKO_FEATURES, and verified license state. Feature-gated rows may exist in the schema before the runtime behavior is active.
| Feature key | Controls |
|---|---|
| sso | Plugin-backed SSO signin flows |
| approvals_policy | Advanced approval policy behavior |
| audit_chain | Hash-chained audit recording and export |
| dual_identity_audit | Human plus agent identity audit context |
| install_policy | Install governance for plugins and skills |
| behavioral_alarms | Behavior threshold sweeps and alerts |
| security_profiles | Security posture presets |
| vault | Managed secret storage |
| data_access_governance | Data access governance controls |
| context_versioning | Personal memory layer resolution |
Default admin actions
Default policies treat sensitive administration as approval work. User administration, source config, channel management, data-source management, and plugin install or uninstall are not ordinary background writes.
- Use admin approver roles for source_config_admin and data_source_admin.
- Keep plugin_management approval aligned with your deployment profile.
- Leave external_default in approval_required mode unless a specific lower-priority policy is safer.
- Prefer narrow action kinds over broad catch-all plugin operations.