Security and execution controls
Set the conditions under which agents can act.
Recuriant applies configured policy before actions change external systems. This page explains the enforcement path, human approvals and current identity and recording limits.
Apply policy on the execution path.
Workflow steps, connector actions and MCP calls use the same dispatch path. With a declared policy, mutating actions are evaluated after their inputs are resolved and before they run.
A configured policy that cannot be loaded blocks mutating actions. Read-only actions skip the policy-tier check but remain subject to applicable scope checks. A workspace without a declared policy runs ungoverned.
- agent:hotfix-author github.comment #4412 L1 · allowed
- verify-hotfix stripe.refund.create 412.00 USD refused · scope_missing
- hotfix stripe.refund.create 412.00 USD L2 · held
- person oncall approval verdict=approve approved
- nightly-triage github.label.add stale refused · policy_unavailable
Classify actions by reversibility and impact.
An action declares how reversible it is and how far it reaches. Reversible and low impact is L1. Irreversible with medium or high impact, or hard to undo with high impact, is L3. Other mutating actions are L2, including actions with no classification.
Allow the action.
The configured policy allows the action to run.
Wait for human approval.
The action waits until an authorized person resolves its approval. The approval state must be stored before the action can continue.
Refuse the action.
The action does not run. Its refusal can be inspected when the decision record is available.
Your policy maps each tier to allow, gate or deny. Financial actions can be held for approval and cannot be configured to run unattended. Configured daily and campaign spending limits can raise an action's tier.
Keep human decisions attached to the work.
A held step pauses durable execution. Its wait survives restarts and deployments; after approval, the workflow resumes at the held step.
- An approval is single-use and bound to the action step.
- Only the named approver or an administrator can resolve it, from a human login. An API key cannot approve.
- The approver's identity is stored with the approval decision.
- The wait defaults to 24 hours or the duration set by your policy. When it expires, the step is denied unless the policy specifies grant or escalation.
Use a configured identity for each agent role.
For a declared, enabled role identity, Recuriant requests a short-lived token carrying that role's scopes before dispatch. If token issuance fails, the dispatch does not start. Scope checks apply to actions called with that identity.
Current identity boundaries
- Workspaces without a declared policy, and roles without a declared enabled identity, can still use a shared credential.
- Workflows written by agents are validated when saved. Actions are checked against the identity presented when they execute.
- Direct agent-to-agent dispatch is not enabled through the dispatch API. This path does not yet use delegated token exchange.
Inspect execution and policy decisions.
Runs expose step results. Available policy decisions identify the action, resolved inputs and rule applied, with approver details for held actions. Both are readable through the API as JSON.
Allow and deny audit writes are best effort unless they are part of an operation that requires persistence. If approval state cannot be stored, the action does not run; the workflow must retry before the approval can be resolved.
- execution_id
- the run it belongs to
- action, inputs
- the action and its resolved inputs
- decision
- allow, gate or deny
- rule_fired
- the rule that decided it
- tier
- L1, L2 or L3
- agent_owner
- the human who owns the agent
- approved_by, approval_consumed_at
- who approved it, and when it was used
Choose the deployment with your team.
Recuriant runs on Kubernetes using a Helm chart, with durable workflow execution, Postgres and Redis. Role identities use an OpenID Connect provider. Enterprise deployments in a customer's cluster are arranged with the team; a packaged guide is not yet published.
Review the current assurance level.
Recuriant currently holds no SOC 2, ISO 27001 or HIPAA certification. Tell the team which requirements your security review must satisfy.
Deployment-specific identity, retention and access requirements are discussed during an Enterprise review.
Access and product terms.
- Pre-registration costs nothing. Paid access is not open for public signup. We will contact you when access opens.
- Execution and concurrency limits for each plan will be confirmed at launch.
- Runs and available policy decisions are readable through the API. Allow and deny audit writes are best effort; an approval hold requires its state to be stored.
- Recuriant is proprietary, and its source is not publicly available. A deployment in your own cluster is arranged on Enterprise.
Discuss your workflow's requirements.
Pre-register for paid access. For a technical discussion, email the team with your workflow, tools and required approvals.