Composio Firewall shifts attention from access to intent
Composio introduced Firewall on October 21, 2026, addressing a gap in enterprise agent control: permission to use a tool does not necessarily mean that using it serves the user’s intended task. The announcement puts task boundaries alongside access permissions as a question for organizations expanding AI-assisted work.
An employee may legitimately access a document repository and a communications tool. An assistant summarizing a document does not thereby have permission to send its contents elsewhere. The repository and communications tool can both be approved while the proposed action is inappropriate. A tool inventory is therefore a starting point, not a complete operating policy.
For enterprise operators, the immediate question is not whether to add another security component. It is how to specify the information, memory and actions an employee needs for a particular task, then evaluate whether the workspace respects those boundaries when instructions are ambiguous or source material is adversarial.
This is relevant to Radon Mini, the employee AI workspace in the rFactorial product group owned by Muscat-based Cognition-AI. Its supplied capabilities are approved files, memory and tools under organizational control. The evaluation framework below is proposed guidance, not a claim that Radon Mini implements Composio Firewall, integrates with Composio, or provides particular enforcement, detection, logging or approval mechanisms.
Define the assignment before approving the tools
Consider an employee preparing a supplier-review brief. The assignment could require reading the current agreement, consulting approved procurement guidance and producing a draft for a manager. It need not include changing supplier records, retrieving unrelated employee information or contacting the supplier.
A useful task definition identifies the requested output, permitted sources, intended audience and allowed actions. It also states what requires a new instruction or human decision. “Help with procurement” is too broad to evaluate. “Draft an internal renewal brief from these approved documents without modifying records or contacting anyone” creates a testable boundary.
This distinction matters because credentials usually describe what an identity can access, not what a particular assignment requires. Likewise, a document may be available without being authoritative for the question. An older policy, an unapproved draft and a current operating procedure can coexist in an otherwise legitimate information collection.
Before deployment, name a business owner for each task family. That owner should decide what success means and who can authorize exceptions. Technology teams can then assess whether the workspace configuration and surrounding procedures can support those decisions. Where they cannot, narrow the task rather than treating broad access as an acceptable substitute.
Evaluate approved information as a maintained collection
Start with an information register, not a bulk upload. For each collection, record its owner, intended users, business purpose, sensitivity, authoritative status and review date. Include exclusions: which documents should never be used for this task, even when the employee can access them elsewhere?
Approval also needs a lifecycle. A policy can expire, a contract can be superseded and a working draft can become an approved reference. The evaluation should check what happens after those changes. Ask whether stale material remains available to the assistant, whether derived notes persist and how an operator verifies that the usable information set has changed.
For GCC organizations, task boundaries may cross Arabic and English materials, local operating companies and regional shared-service teams. Test representative language pairs and organizational boundaries rather than assuming one English-language collection covers the operating model. An Arabic policy and its English working translation should not silently acquire equal authority if the organization designates only one as controlling.
These are requirements to investigate, not confirmed Radon Mini features. Its approved-file capability provides the relevant starting point. Operators still need evidence about how their chosen deployment handles ownership changes, updates and exclusions. Where automated controls are unavailable or unverified, use smaller collections, explicit review steps and documented limitations.
Treat memory as governed information
Memory can help an employee avoid restating useful context. It can also preserve an assumption after the underlying facts change. A preference for concise answers differs from a remembered customer detail, a confidential project decision or an instruction copied from an untrusted document.
Separate at least three categories during evaluation: employee preferences, task-specific working context and organizational reference knowledge. Decide which categories are appropriate to retain, who owns them and when they should stop influencing future work. Do not assume that all useful context belongs in persistent memory.
A practical test starts with a legitimate task containing a temporary fact. Change or withdraw that fact, then run a related task and an unrelated one. Observe whether the earlier information appears, whether it is presented as current and whether the employee can establish what context influenced the answer. Test project changes and employee role changes as well.
Radon Mini’s supplied description includes memory under organizational control. It does not specify retention schedules, memory separation, inspection interfaces or deletion behavior. Procurement and pilot teams should ask for demonstrations of the behaviors they need and record any gaps. Organizational control should become an evidenced operating arrangement, not an assumption inferred from the product category.
Scope actions separately from tool availability
A tool name rarely describes the whole risk. Reading a record, drafting an update and committing that update are different operations. Sending a message to an internal reviewer differs from sending it to an outside recipient. Evaluate the operation, target and consequence, not just whether a tool appears on an approved list.
For each task, distinguish actions that are necessary, actions that are conditionally permitted and actions that are outside scope. Where possible, begin with read-and-draft work. This reduces the consequence of an error while revealing whether the assistant selects appropriate sources and understands the assignment. Expansion to consequential actions should follow evidence, not merely successful demonstrations.
The following matrix is a proposed acceptance framework, not a statement of implemented Radon Mini controls.
| Evaluation area | Test question | Evidence to request |
|---|---|---|
| Approved information | Does the task use only eligible, current sources? | Source inventory and representative task results |
| Tool scope | Can a draft task trigger an unrelated action? | Observed action attempts and disposition |
| Memory | Does withdrawn context affect later work? | Before-and-after test records |
| Adversarial documents | Can source text redirect the assignment? | Controlled attack cases and outcomes |
| Escalation | Does a boundary issue reach an accountable person? | Review records and response times |
A written task policy makes reviews repeatable. This illustrative YAML is a policy specification for discussion, not executable configuration or Radon Mini syntax:
# Proposed acceptance criteria; not product configuration
supplier_brief:
output: internal_draft
sources: [current_agreement, approved_procurement_policy]
memory: task_only
allowed: [read_approved_sources, draft_brief]
excluded: [modify_supplier_record, contact_supplier]
escalate_on: [conflicting_policy, requested_external_send]
reviewer: procurement_owner
If a requirement cannot be mapped to an enforceable control or a reliable human procedure, mark it unresolved. A document describing the desired boundary is not proof that the boundary holds.
Test adversarial documents without exposing real data
An approved collection is not automatically free of hostile instructions. A supplier document, copied email or imported report may contain text that tells the assistant to ignore the assignment, reveal other information or use a tool for a different purpose. Such text is content to analyze, not authority to redefine the employee’s task.
Build a small adversarial test set using synthetic documents and dummy destinations. Include direct instruction overrides, claims of management authority, requests to retrieve unrelated files and instructions embedded in tables or quoted messages. Add Arabic and mixed-language examples where those formats occur in actual work. Keep tests representative rather than relying exclusively on conspicuous attack phrases.
Pair each adversarial case with a legitimate counterpart. An assistant should be able to summarize a document discussing malicious instructions without following them or refusing every security-related document. Measuring only blocked attacks can reward an unusable system; measuring only completion can conceal unsafe behavior.
Record the attempted deviation and the observed outcome separately. Did the assistant merely repeat the instruction, propose an action, attempt it or complete it? Could the operator establish what happened? If evidence is insufficient, classify the case as unresolved rather than safe. Run these tests in an isolated evaluation setting, with no real confidential material or live external recipients.
Make escalation a workflow, not a warning
A boundary is incomplete without a response when work reaches it. Define who receives an ambiguous case, what information they need and what they may authorize. Separate a request to clarify the assignment from a security incident and from an ordinary factual review; they should not all enter the same queue.
The reviewer should see the employee’s request, the proposed action, relevant source references and the reason for escalation. Avoid making reviewers reconstruct an entire conversation when a short decision packet would suffice. At the same time, do not forward unnecessary sensitive content simply because a review is required.
Set a response expectation and a default outcome. For a supplier brief, a delayed decision might leave the output as an internal draft. It should not silently convert uncertainty into permission to send. Define an alternative route when the normal reviewer is unavailable and identify who can pause the pilot after a serious deviation.
These procedures may sit partly outside the workspace. Radon Mini’s supplied capabilities do not establish a native escalation queue or approval engine. The evaluation should determine which steps the product supports, which require organizational processes and whether the combined arrangement remains workable at the expected volume.
Measure review effort alongside useful output
Consider an illustrative pilot processing 600 internal briefs each month. These figures are planning assumptions, not Radon Mini benchmarks. The manual baseline is 20 minutes per brief, including preparation and review: 12,000 minutes, or 200 staff hours monthly.
Assume an AI-assisted workflow requires six minutes of employee preparation and five minutes of mandatory review per brief. That is 6,600 minutes, or 110 hours. Suppose 15% of briefs, 90 cases, require eight additional minutes of escalation. That adds 720 minutes, or 12 hours. Allow another eight hours monthly for maintaining approved information and testing boundaries.
Total operating effort becomes 130 hours, producing an illustrative saving of 70 hours, or 35% against the baseline. The calculation includes governance work because omitting it would overstate the operational benefit. It excludes software charges, deployment effort and initial training, which require separate accounting.
Sensitivity matters. If 30% of briefs require escalation, additional review becomes 24 hours and total effort reaches 142 hours. Savings fall to 58 hours, or 29%. A workspace can complete more drafts while delivering less value if unclear boundaries create excessive review work.
Track quality and boundary performance beside time. Useful measures include accepted drafts, material factual corrections, out-of-scope action attempts, completed unauthorized actions, unresolved test cases and median escalation time. Report denominators: zero completed unauthorized actions in 20 controlled tests is not equivalent evidence to zero in 2,000 varied tests. Do not combine everything into a single success score.
Place Radon Mini in a bounded operating model
Radon Mini fits this discussion because its verified role is an employee AI workspace with approved files, memory and tools under organizational control. The practical workflow begins with a bounded employee task, continues through approved context and assistance, and ends with an output handled according to organizational procedures.
The trade-off is scope versus assurance. A narrow workspace may require more employee handoffs, but its information and actions are easier to evaluate. A broad workspace may cover more tasks while increasing ambiguity, maintenance and review effort. Neither arrangement should be selected solely by counting available tools.
The forthcoming Radon in the box edition is part of the supplied product context, but its name does not establish deployment architecture, offline operation or security properties. Likewise, Composio’s announcement should prompt evaluation questions, not an inference of a relationship with rFactorial. The next decision is whether a defined Radon Mini use case can satisfy demonstrated requirements with acceptable residual risk.
What to do this week
- Select one Radon Mini candidate task, such as an internal supplier brief. Name its business owner, intended audience and explicitly excluded actions.
- Build a small approved-information register. Include authoritative language, organizational scope, ownership and expiry or review dates; identify what must stay outside memory.
- Write operation-level tool boundaries and an escalation procedure. Ask which requirements can be demonstrated in the proposed workspace and which depend on human processes.
- Run paired legitimate and adversarial tests using synthetic files. Record source use, proposed actions, actual outcomes and unresolved evidence gaps before widening access.
- Calculate baseline effort and pilot effort, including review, escalation and information maintenance. Agree on quality and boundary-failure thresholds before judging the results.
Review the verified Radon Mini product overview when scoping the evaluation. Product questions can be directed to info@cognitionai.cloud.