Policies and approvals
Every governed tool call resolves to one gate plus zero or more obligations. The gate is the routing decision; the obligations stack on top of it.
- Gate:
permit,require approval, ordeny. - Obligations: redaction (shape what is stored in the activity record) and re-authentication (require the person to re-verify before the call runs).
A single call can be permit with redaction and re-authentication at the same time. Access rules are configured per group and toolkit, not per individual agent. Members can additionally tighten the rules on their own toolkits and personal files. The whole hierarchy is tighten-only: an org-wide policy floor sets the minimum, group rules tighten it, and a member can tighten their own toolkits further, never loosen.
Safety profile buckets
When you publish a toolkit to a group, CortexHub materializes three active bucket policies by safety profile:
| Profile | Default decision |
|---|---|
| Read | Permit |
| Write | Permit |
| Destructive | Require approval |
Admins can edit bucket decisions and add tool-specific rules on the published toolkit's Policies tab. Tool policy writes run a compile-preview validation before save. Only published entitlements and active policies affect member connect and invoke.
On top of these rules, a runtime safety floor always applies. Money movement, irreversible destructive actions, and exporting regulated data are escalated to require approval automatically, even if a rule above would have permitted them. The floor can only make a call stricter, never looser.
Policy obligations (require approval)
When a rule decision is require approval, configure obligations on the group policy:
| Field | Description |
|---|---|
| Accountability | End user (the person running the agent consents) or backoffice (your team approves at a routed destination) |
| Destination | When backoffice: the channel this rule routes to (the built-in Approvals inbox, a Slack channel, or a webhook). Leave unset to use the org default. See Approval routing below |
| Personal channels | When end-user accountability applies to an autonomous run: notify the member on their own Slack or mobile channels |
When a call needs end-user consent, an interactive run shows the prompt in the client and an autonomous run notifies the member on their configured channels. The call is parked until a decision is recorded, then CortexHub runs the tool and returns the result. The client polls for completion; no second chat confirmation is required. Developer-level detail on the consent and task flow is in the MCP API overview.
Two further obligations stack on the gate rather than replacing it:
- Redaction shapes what is written to the stored activity record. It is storage-only: the agent still receives the full call and the full response, so it never silently changes the result. To block a value, use a gate (require approval or deny), not redaction.
- Re-authentication (step up) asks the acting person to re-verify before the call runs. It is realised live only when an end user is present in a browser session. For an autonomous run (a co-worker or an SDK agent with no person present) it degrades to require approval instead, so the call never dead-ends. Step up is authored by admins only.
Multi-group merge
A member in multiple groups receives the most restrictive combined gate: deny beats require approval beats permit. Obligations are not a competition: every redaction and re-authentication obligation from every matching rule is applied. Backoffice accountability always wins over end-user accountability, so a looser rule can never weaken your team's oversight.
Compliance profiles
A compliance profile is a named bundle of org floor rules that you can apply to the org in one step. Applying a profile turns its rules into active floor rules that sit underneath your group and tool policies as a tighten-only floor: a profile can only make access stricter (require approval, step up, redaction, or deny), never looser. Group and tool policies cannot relax what a profile sets.
Find compliance profiles in Org space on the Policies page.
Curated profiles
CortexHub ships a small gallery of curated profiles for common regimes:
| Profile | Typical use |
|---|---|
| HIPAA | Organizations handling protected health information |
| PCI DSS | Organizations handling cardholder data |
| Financial operations | Finance and treasury workflows |
| Least privilege | A conservative default floor for any org |
To use one, open it from the gallery, review its rules, and Apply. Each rule becomes an enabled floor rule. You can apply more than one profile; their rules stack, and the most restrictive outcome always wins. To stop enforcing a curated profile, open it and Remove to unapply it. Unapplying disables only the floor rules that no other applied profile still relies on, so shared rules stay in force.
Curated profiles are read-only as bundles: you cannot rename a shipped profile or edit its curated rule set. To diverge from a shipped baseline, create your own custom profile (below) and tailor it.
View and edit a profile's rules
Open any profile to see its rules. Each rule is an org floor rule: a condition plus a decision (require approval, step up, redaction, or deny), with the accountability and routing that apply when it triggers.
For a custom profile you can:
- Add a rule to extend the bundle.
- Remove a rule to drop it from the bundle.
- Rename or describe the profile.
For a curated profile, the rules list is for review only. Applying or removing the whole profile is how you turn its rules on or off.
Create a custom profile
Choose Create custom profile to start a new, empty named bundle. Give it a name and an optional description, then add rules one at a time. Custom profiles behave exactly like curated ones once applied (tighten-only floor, most-restrictive merge), but you own their name and rule set and can edit them at any time. Delete a custom profile to remove it and disable the floor rules only it relied on.
Approval routing
When a rule's accountability is backoffice, the approval prompt is sent to a channel instead of an end user.
The Approvals inbox is the default
Every org has a built-in Approvals inbox. With no other configuration, backoffice approvals land here, where reviewers act on them from the Org space Approvals page. This is the default destination and is always available; you never have to set it up.
Add Slack or webhook channels
Connect channels under Settings -> Integrations -> Approval Channels so backoffice prompts reach your team where they already work. Once a channel is connected, you choose it per rule (see below).
| Channel | What it does |
|---|---|
| Approvals inbox | Built-in. Reviewers act from the Approvals page. Always present. |
| Slack | Posts an approval card to a Slack channel. Anyone who can see the message can approve or deny; the decision is attributed to their Slack identity (no CortexHub account needed). Connect Slack once in Settings -> Integrations first. |
| Webhook | Sends a signed approval payload to an HTTPS endpoint you control, and accepts your decision callback. See Integrations. |
Route a specific rule to a channel
You do not have to send everything to the same place. On any require approval rule with backoffice accountability, pick the channel for that rule on the group's Policies tab or in a compliance profile rule. For example, route destructive finance actions to a Slack channel the finance leads watch while everything else stays in the Approvals inbox. A rule with no channel of its own falls back to the built-in Approvals inbox.
Who approves: end user vs backoffice
Accountability decides who is asked to approve, which is the heart of an audit trail:
- End user accountability asks the person running the agent to consent. Interactive runs show an in-client prompt; autonomous runs notify the member on their personal channels. The decision is attributed to that member.
- Backoffice accountability asks your team instead, at the routed channel. The decision is attributed to the reviewer who acted (a reviewer in the Approvals inbox, a Slack approver, or your webhook system).
Use end-user accountability when the person taking the action should own the decision, and backoffice accountability when a separate reviewer must sign off regardless of who triggered the call.
The Org space Approvals page is for review and audit across all channels. After a decision is recorded anywhere, the calling client picks up the result and the call completes.
End-user consent
When accountability is end user, the call is parked and the person running the agent is asked to consent. An interactive run shows the consent prompt in the client; an autonomous run delivers the prompt on the member's personal channels. Once consent is recorded, the call resumes and returns its result. The developer-level flow (how a client surfaces the prompt and waits for the result) is covered in the MCP API overview.
Approvals history
The Approvals page lists requests for compliance and investigation. Backoffice decisions happen at the routed channel (the Approvals inbox, a Slack channel, or a webhook). Sensitive fields may be redacted per your org privacy settings.
Autonomous invocations
A call is interactive when a person is present (chat) and autonomous when no person is (a scheduled routine, a background job, or an always-on backend agent).
When a rule requires end-user approval and the run is autonomous, CortexHub parks the call, sends one notification to the member's bound approval channel (routine override, then co-worker default, then active personal channel), and waits until the member approves or denies, or the request times out. Interactive runs use the in-client consent prompt instead. Re-authentication obligations that cannot be satisfied without a person present degrade to require approval on the same path, so an autonomous call never dead-ends.
Approval webhook
Connect an outbound approval webhook under Settings -> Integrations -> Approval Channels. CortexHub sends signed approval payloads and accepts a decision callback from your system. See Integrations.