Access control and shared responsibilities
Assign policy owners, approvers, and credential responsibilities before connecting sensitive workflows.
On this page
Separate human and runtime authority
Workspace membership governs administrative and approval access. Environment API keys authenticate supported runtime requests. Edge devices and operator tokens have their own lifecycle. Use a separate credential for each supported purpose and keep the active workspace and environment explicit.
| Authority | What to establish | Verification |
|---|---|---|
| Policy administration | Named ADMIN/OWNER members and an agreed change-review process | A permitted member can change the test policy; an unauthorized member cannot |
| Human approval | ADMIN/OWNER or the supported membership approval permission | An authorized human resolves the checkpoint and the record identifies the resolution |
| Runtime API access | Environment, owner, expiry, and supported identity binding | A harmless request produces the intended environment and identity context |
| Device access | Device owner, login scope, installation, and revocation process | The expected hook produces an attributable decision |
| Automation | Operator token role, expiry, CI secret storage, and authorized commands | Read-only automation cannot perform the writes reserved for administrators |
An API key alone is not human approval authority. Approval checks use current membership and supported separation-of-duties constraints. Confirm how requester identity is established for your integration before relying on those constraints.
Agree on operational ownership
| Responsibility | Kastra provides | Your organization operates |
|---|---|---|
| Action control | Supported evaluation, integration behavior, and policy effects | Connected paths, tool credentials, host configuration, and underlying system permissions |
| Policy lifecycle | Authoring, revisions, testing/replay, activation, and rollback capabilities | Rule intent, reviewer assignment, acceptance cases, promotion, and change approval |
| Human review | Checkpoints, authorized resolution, and supported notification channels | Approver coverage, escalation, response expectations, and timeout choices |
| Evidence | Recorded decisions, verification, and supported exports | Collection scope checks, review access, retention requirements, and incident interpretation |
| Vendor assurance | Security review through the Trust Center and agreed supporting material | Vendor risk decision, data-use approval, and contractual review |
These are operating responsibilities for a rollout. Deployment and contractual commitments are established in the applicable agreement.
Integrate identity deliberately
Enterprise identity supports the documented SAML and SCIM flows. Test login, provisioning, role defaults, deactivation, and recovery for your IdP. Keep a controlled recovery path during configuration.
For application policies, distinguish caller-supplied labels from credential-bound identity. Agent inventory helps identify and scope work; it does not independently attest the executable that sent a request.
Verify revocation and offboarding
Review membership, API keys, device credentials, operator tokens, and OAuth grants independently. Revoking a Kastra device does not uninstall its hooks or remove access to the underlying tools. Where an integration can fail open, remove sensitive access at the application or infrastructure boundary as required by your runbook.
Workspaces and roles · Account MFA · Devices · Operations guide