From AI Answers to Governed Action: Four Control Layers
A useful AI answer is not yet authorized business activity. This practical framework explains the context, action-contract, decision, and execution controls needed to turn assistance into accountable work.
On this page
Key takeaways
An AI answer can be useful without having any authority to change a business record. Treat understanding, proposing, approving, and executing as separate stages.
Review an app connection against its purpose, permissions, data direction, mapping, owner, and observed result. Distinguish saved configuration from verified data movement.
·6 min read
Security & Trust
Four control layers provide a practical review model: context boundary, action contract, authorization and decision, and execution and evidence.
Read and recommend modes should not produce business-side effects. A draft can prepare structured work without committing it. Execution depends on the action, current permissions, workspace policy, and supported integration.
Approval is one control, not a substitute for authorization. A system should check the person, workspace, target record, source version, and relevant domain permission again when the action runs.
Safe automation needs explicit limits, idempotency, outcome verification, and a path for reconciliation when an external effect is uncertain.
AI becomes operationally interesting when it moves beyond explaining information. A summary can become a proposed transaction. A project review can become a follow-up draft. An external agent can request a change through an API. Each step may save time, but each also moves closer to changing shared business state.
The challenge is not to make an AI answer sound more certain. It is to make the path from answer to action explicit, bounded, and reviewable.
This article uses four control layers to examine that path. The layers are an editorial framework, not the official name of a Figena product architecture. Figena’s public action vocabulary is Read, Recommend, Draft, and Governed execution. The framework below helps a team ask what must be true underneath those modes before a proposed action should be allowed to affect real work.
An answer is not authority
A fluent answer can collapse several different ideas into one sentence: what the user asked, what the model inferred, what the system permits, and what should happen next. A governed workflow separates them.
Consider a request such as, “Review this month’s expenses and fix anything miscoded.” It contains at least four jobs:
identify which workspace and records the person is allowed to use;
analyze those records and explain possible exceptions;
prepare precise changes with enough context to review them;
apply only the changes that are authorized under current policy.
The first two jobs can often remain read-only. The third can create a draft. The fourth changes business state and therefore needs a much stronger contract. If a system treats the original sentence as permission for all four jobs, it has skipped the most important controls.
The product experience described on the Cilila AI page follows that progression: begin with context, produce a structured next step, and apply the relevant permissions and review rules before a material change.
The four-layer model at a glance
The four layers answer different questions. Passing one layer does not imply that the next layer will pass.
Scrollable article table
Control layer
Primary question
Examples of useful evidence
What a failure should do
1. Context boundary
What information may this request use right now?
Workspace, principal, allowed entities, data classification, source revision
Is this actor allowed, and does policy require a human decision?
Current role and capability, target access, policy snapshot, approval or rejection
Return a draft, request approval, or deny
4. Execution and evidence
Did the intended effect occur once, and can it be investigated?
Idempotency key, attempt, result, readback where supported, audit link, reconciliation state
Avoid unsafe replay and surface uncertainty
This is intentionally a chain. Context does not grant permission. A valid action contract does not approve the action. Approval does not guarantee that execution will still be authorized. A successful request does not prove that an external provider reached the expected state unless that state can be verified.
Layer 1: Establish the context boundary
Before an AI system reasons about business data, it needs a server-authorized view of what the current request may use. That boundary should not be inferred from what happens to appear in a conversation window.
For an operational request, the context boundary can include:
the signed-in principal or service identity;
the active workspace and organization;
the records that identity may inspect;
the purpose and data classification of the request;
the exact version of a source record used to prepare a proposal;
the capabilities and product entitlements available at that moment.
This matters even for apparently harmless analysis. A person may be able to view one project but not another. An external tool may have access to selected resources but not an entire workspace. A record mentioned earlier in a conversation may have changed or become unavailable. Reusing old context without checking it can turn a valid earlier answer into an unauthorized or stale later action.
A strong boundary is therefore evaluated at the time the system generates or refreshes the response. It resolves references against current server-side permissions and fails closed when a required entity or revision cannot be verified. The model receives authorized context; it does not define its own authority.
Source revision is especially important when a recommendation may become a change. If a teammate edits a record after the AI prepares an update, the right outcome is usually a conflict or fresh draft, not silent application to the newer record.
The context layer is also where data minimization begins. A request should receive the records and fields needed for its purpose, not every field the workspace happens to contain. That principle applies to a person using a product interface and to an external tool using a scoped connection.
Layer 2: Define the action contract
Once the system understands the request, it still needs to determine whether the proposed next step is a supported action. Natural language is too flexible to serve as an execution contract.
An action contract turns an intention into a bounded object. Depending on the action, it can identify:
an action type and owning business domain;
the action mode: read, recommend, draft, or execute;
a risk level and the capability required to inspect or perform it;
validated input and a human-readable preview;
the source-version rule that protects against stale changes;
the execution mechanism and expected effect;
idempotency, readback, and compensation or reconciliation behavior;
the evidence the action is expected to produce;
whether confirmation or stronger verification is required.
Those fields answer a question that prose cannot: “What operation is the system actually proposing?” A sentence such as “clean up the duplicates” could imply a report, a merge plan, or destructive deletion. Each has a different owner, risk, and review requirement. If the proposal cannot be mapped to a registered and validated action, it should remain an explanation rather than becoming an improvised write.
The four action modes are useful here because they describe effect, not intelligence.
Read retrieves, summarizes, or analyzes permitted information without changing business data.
Recommend adds judgment or a suggested next step but still has no business-side effect.
Draft prepares structured work and exposes what would change. Creating the draft is not the same as committing its proposed effect.
Governed execution performs a scoped, supported action only after its permissions, policy, and required decision have passed.
The contract must be specific to an implemented action. It should not imply that every domain supports every mode. Some workflows can execute after confirmation. Others deliberately stop at a recommendation, export, or manual handoff. A high-risk people plan, for example, may be prepared for review while the People domain remains responsible for any later change.
Layer 3: Separate authorization from the decision to proceed
An action can be well defined and still be forbidden. The third layer checks who may do it, which target they may affect, and whether organizational policy requires a human decision.
Two kinds of authority matter for cross-domain AI actions:
AI authority determines whether the principal may use the relevant AI or agent capability.
Target-domain authority determines whether that same principal may inspect or change the underlying transaction, client, project, person, or other resource.
Neither should fall back to the other. Permission to ask AI for help does not create permission to edit payroll, export recruiting data, or delete a business record. Conversely, permission to edit a record does not automatically authorize every AI or external-agent pathway.
Authorization should also include the workspace, tenant boundary, target access, product entitlement, and current action policy. These checks matter again at execution time because roles and records can change while a draft is waiting.
Human approval sits inside this layer, but approval is not the whole layer. For a review-first flow, the system presents a draft with its impact and relevant context. An authorized person can confirm or reject it. The approver’s authority is checked; the click is not treated as a universal override.
Different paths may apply different policies. Cilila’s product-native assistant mutation path is designed around structured drafts and explicit confirmation. OpenPort is draft-first by default for external tools, while allowing an administrator to configure conditional direct execution for supported actions. The OpenPort overview introduces its connection, mapping, monitoring, and review workflow; exact action governance depends on current policy and the supported integration.
That configurable path needs careful wording. It does not mean an external agent receives blanket autonomy. Standard create or update actions can run directly only when the relevant policy is enabled and current, the request passes present identity, scope, tenant, target-access, and idempotency checks, and any configured allowlist or expiry condition passes. A high-risk route also requires active time-bounded authorization and an explicit justification; configured limits still apply, and a matching preflight is required when the current policy says so. Some domains remain draft-first even when broader automation is enabled.
This is why a simple rule such as “low risk is automatic; high risk always waits” is not sufficient. A better decision sequence asks:
Does the action have a business-side effect?
Is this particular action supported and registered?
Does the principal have both AI and target-domain authority?
Is the target still accessible in the same workspace?
What risk and source-version rule apply?
Does current workspace policy permit direct execution?
Is confirmation or stronger verification required for this route?
The answer can be read-only output, a draft awaiting review, a policy-authorized execution, or a denial. The model should not choose among those outcomes on confidence alone.
Layer 4: Execute once, verify the result, and preserve evidence
The final layer begins after the system has a valid action and a valid decision. It controls the transition from intended effect to actual effect.
Execution should start from the governed action object, not by rereading a conversational sentence and interpreting it again. The system rechecks current permissions and relevant source state, validates the payload, and attaches a stable request identity. For mutations, that identity supports idempotency: a retry of the same approved request should not casually create a second transaction, send a duplicate instruction, or apply the same update twice.
Idempotency is necessary but not magical. A provider may accept a request just before a timeout, or the platform may receive success and then fail while recording it. Automatically trying again can be more dangerous than pausing.
A governed execution path distinguishes at least three outcomes:
the action failed before a material effect and can be reported as failed;
the action completed and its result was recorded;
the external effect may have occurred, but the final state is uncertain and requires reconciliation.
Where a provider or domain supports reliable readback, the system can compare the resulting state with the intended effect. Where it does not, the evidence should say what is known rather than inventing certainty. Reconciliation records, provider references, and operator notes can preserve the investigation path without pretending that every integration offers the same proof.
The evidence trail should connect the proposal, authorization, decision, attempt, and outcome while minimizing sensitive content. Useful records include identifiers, timestamps, action and policy versions, payload fingerprints, approval or denial, execution status, error codes, and links to the affected record. Audit events can use allowlisted and redacted details rather than storing an entire prompt or hidden model reasoning.
This makes the history useful for operations as well as assurance. A teammate can determine whether a request was denied because of policy, blocked by a changed source record, completed once, or placed in reconciliation. The goal is not to accumulate the largest possible log. It is to retain enough trustworthy evidence to explain and safely continue the work.
A walkthrough: preparing a transaction from a request
Imagine that a workspace member asks Cilila to create a transaction from a receipt. This example illustrates the layers; it does not mean every input, domain, or subscription supports the same action.
1. Resolve permitted context
The system identifies the active workspace, authorized account context, and relevant source material. If the referenced account is unavailable or the source cannot be resolved, the request stops rather than substituting another record.
2. Analyze without changing state
The AI can extract candidate fields and explain uncertainty. At this point, the output is analysis. It has not created the transaction.
3. Build a registered draft
The candidate becomes a validated transaction draft with its action type, owning domain, risk, required capability, payload, and preview. The draft is linked to the session and message that produced it and receives a stable identity for later processing.
4. Present the proposed impact
The reviewer sees what will be created and can inspect or edit the relevant values. The interface distinguishes a pending proposal from a confirmed or completed result.
5. Confirm under current authority
An authorized person confirms the draft. The system checks both the AI pathway and the transaction-domain permission. If access changed while the draft waited, the earlier proposal does not override the new state.
6. Execute through the owning domain
The confirmed payload is sent to the transaction executor with its workspace, correlation information, idempotency identity, and applicable source-version expectation. The owning domain—not free-form model output—performs the change.
7. Record the outcome
The draft and execution receive their resulting states. A successful result can reference the new transaction. A known failure is recorded as a failure. An ambiguous external outcome would move to reconciliation rather than being silently replayed.
The same shape can inform an external-agent workflow, although its policy and executor may differ. Developers evaluating those paths can start with the developer resources, while teams using command-line access should treat the Figena CLI as a governed client of server-side rules, not as a way around them.
A review checklist for governed AI actions
Use this checklist when evaluating a new AI-assisted workflow. A “no” does not always mean the workflow is impossible; it often means the safe current output should be a recommendation or draft rather than execution.
Context
[ ] Is the identity and active workspace explicit?
[ ] Is context resolved from current server-side permissions?
[ ] Are only the necessary records and fields included?
[ ] Can the system detect a missing, changed, or unauthorized source?
Action contract
[ ] Is the action registered and owned by a real business domain?
[ ] Is its mode, risk, required capability, and availability explicit?
[ ] Are input and preview shapes validated?
[ ] Are idempotency, source revision, readback, and reconciliation rules defined where relevant?
Authorization and decision
[ ] Are AI authority and target-domain authority checked independently?
[ ] Are workspace, tenant, target access, and entitlement checked?
[ ] Does policy clearly choose denial, draft, approval, or permitted direct execution?
[ ] Can a sensitive policy change require stronger verification and expire automatically?
Execution and evidence
[ ] Does execution use the approved structured payload rather than reinterpret prose?
[ ] Are permissions and source state checked again immediately before the effect?
[ ] Is the operation safe to retry, or does uncertainty move to reconciliation?
[ ] Does the resulting evidence distinguish intent, decision, attempt, and outcome?
[ ] Are sensitive fields minimized or redacted?
Frequently asked questions
Are these four layers an official Figena product model?
No. They are a practical framework for this article. Figena’s public product language describes four action modes—Read, Recommend, Draft, and Governed execution. The layers explain the controls that should surround the movement between those modes.
Does every AI request pass through one shared runtime?
No such claim is required for good governance, and it would be inaccurate to assume it. Cilila actions, external OpenPort requests, platform operations, and domain-specific manual workflows can have different execution paths. They can still apply consistent principles such as scoped context, explicit action contracts, current authorization, idempotency, and reviewable evidence.
Do all writes require human approval?
Approval depends on the route and policy. Cilila’s product-native assistant mutation path uses a draft-and-confirm pattern. OpenPort is draft-first by default, but an administrator can conditionally enable direct execution for supported actions. Standard routes apply any configured allowlist or expiry; high-risk routes require active time-bounded authorization, justification, and idempotency, plus configured limits and a matching preflight when the current policy requires one. Some domains remain draft-first or non-executable regardless of broader settings.
Does approval guarantee that an action will execute?
No. Approval records a decision; it does not freeze permissions or source data. Execution can still be denied if access changed, the source revision is stale, the target no longer belongs to the workspace, the payload fails validation, or the integration is unavailable.
Does governed execution mean the system stores every prompt and model thought?
No. A useful audit trail should identify the action, actors, decision, policy, attempt, and outcome without collecting unnecessary sensitive material. Full prompts and hidden chain-of-thought are not required to prove that a structured action was authorized and processed.
Can an AI system safely automate external actions?
It can automate supported actions within explicit scopes and policies. Safety depends on current authorization, validated inputs, idempotency, a matching preflight when policy requires one, bounded impact, and honest handling of uncertain outcomes. “External” should not be treated as either automatically unsafe or automatically trusted.
Govern the transition, not just the answer
The most important design decision in business AI is not how confidently a system speaks. It is how deliberately the system crosses the boundary from information to effect.
Start with authorized context. Map the proposal to an explicit action contract. Separate domain permission from the decision to proceed. Execute through the owning workflow with safeguards against stale state and duplicate effects. Then preserve evidence that explains what was intended, decided, attempted, and observed.
Those controls let a team use AI for more than conversation without turning every useful suggestion into an invisible write. They also make restraint a supported outcome: sometimes the correct result is an explanation, a draft, a request for review, or a clear refusal.
For teams comparing packaging and availability, the current pricing page identifies Cilila AI and OpenPort as beta capabilities and summarizes their review-oriented boundaries.
Prepare for a lost device with approved backup authentication, a known recovery route, clear business coverage, and checks after access is restored. Use a practical recovery plan.
Check the purpose, content, version, recipient, and delivery method before sharing a business record. Use a practical checklist for internal and external handoffs.
