How Actera works

Actera checks whether a proposed action is within an agent’s authority before your integration executes it.

The decision path

1. Identify the action. The connection key identifies the agent and workspace. Your application supplies an action type, its attributes, and relevant context.
2. Select policies. Actera considers policies assigned to the agent whose scope matches this request.
3. Evaluate rules. Every applicable rule contributes its result. Block takes precedence over Require approval, which takes precedence over Allow.
4. Apply the fallback. If no rule matches, Actera uses the agent’s When no policy matches setting, even if a policy’s scope matched.
5. Enforce the result. In Enforcing mode, the integration allows, pauses, or blocks the action.
6. Record the outcome. After dispatch, the integration reports whether the operation succeeded, failed, was cancelled, or remains uncertain.

New agents default to Allow for unmatched requests. Review that setting explicitly before relying on enforcement. An unavailable or invalid authorization response is an integration error, not permission to proceed.

Monitoring and enforcement

Monitoring evaluates policies and records a decision, including a result of Block or Require approval, without stopping the call. It does not create an approval request or a resumable managed call.

Enforcing applies the decision at the connected action boundary. The plugin or application chooses its mode. The mode shown in Actera reflects the requests received.

Both modes can affect cumulative usage. Monitoring is useful for rollout, but it is not a simulation with no recorded activity.

Policy updates

Draft edits do not change live authority. Publishing makes a new policy version available to new requests from agents already assigned that policy. You do not need to re-save those agents.

Existing decisions retain the version and inputs used when they were made. Retrying an already resolved request with the same idempotency key returns its original decision, even after a policy update.

Approval and completion

Approval authorizes the requested action. It does not execute it. Your integration must preserve the proposed operation, wait for approval, and then continue through its supported execution flow.

Managed SDK and MCP continuations preserve the call and coordinate permission to dispatch it. They still depend on the external provider’s idempotency and on accurate outcome reports. An uncertain outcome needs reconciliation before another attempt.

Policy tests and simulations explain hypothetical outcomes without creating live decisions, approvals, or usage reservations.