The Agentic OS Security Model for Cross-Agent Work

When agents collaborate, risk can cross organizational and technical boundaries. One agent may ask another to retrieve data, run analysis, call a tool, draft a message, or take a step that affects a customer. The receiving agent may have different memory, tool access, evaluation coverage, policy, owner, or reputation. If the system treats that exchange like ordinary chat, it loses the authority path.

OWASP's agentic AI threat guidance is useful here because it starts from the premise that agentic systems bring expanded autonomous-system risks (https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/). Cross-agent work intensifies those risks by adding counterparties, delegated tasks, and multi-hop responsibility.

Cross-agent control map

The control map avoids a common mistake: assuming that interoperability standards automatically solve trust. Standards can make collaboration possible. They do not decide whether a particular delegation is safe.

A safer implementation pattern

The first pattern is least-authority delegation. An agent should hand off the smallest task that achieves the mission, with the smallest data set and tool scope needed. If the counterparty needs broader access, it should request a new receipt rather than inheriting the caller's authority.

The second pattern is evidence freshness. A counterparty that was acceptable last week may be unacceptable after a model change, tool expansion, unresolved dispute, or policy update. The Agentic OS should make trust conditional on the current operating context.

The third pattern is tool-path separation. Agent-to-agent communication and agent-to-tool execution should not collapse into one audit bucket. A message to a remote agent is not the same as a database write. A delegated recommendation is not the same as an externally binding action.

The fourth pattern is blame-resistant recourse. When cross-agent work fails, the system should not let each participant point at the other participant's logs. The delegation receipt should show who requested what, what was accepted, what evidence existed, and which recourse rule applies.

Builder decision checklist before expanding delegation

Builders can make this concrete with a five-step review sequence. First, classify the delegation by consequence: read-only analysis, reversible internal change, external communication, economic commitment, or downstream delegation. Second, choose the minimum counterparty trust requirement for that class. A research helper may need recent evidence and a clean dispute record. A payment-capable counterparty needs a much stronger pact, approval, and recourse story. Third, define the data boundary. The receiving agent should not get full context when a narrowed packet is enough.

Fourth, attach a recertification rule before the workflow launches. The rule should say which changes invalidate the prior trust decision: new tool, new owner, new model class, changed operating policy, disputed prior work, stale evaluation, or expanded customer impact. Fifth, run a failure rehearsal. If the delegated work is wrong, who pauses the workflow, who informs the affected party, what gets rolled back, and what future permission is reduced?

That sequence keeps cross-agent security from becoming a generic warning. It turns the warning into a rollout gate. The organization is not saying "never delegate." It is saying delegation must carry enough evidence that the next reviewer can understand why the handoff was safe for this task and unsafe for a larger one.

Armalo's cross-agent boundary

Armalo's Agentic OS architecture is built around trust-bearing agents, pacts, receipts, evaluation, runtime policy, and reputation. That makes cross-agent work a natural trust problem rather than a pure integration problem. The product-safe claim is that Armalo is building the control layer that lets agents earn and present trust for bounded work. The customer value is visible in the artifacts: delegation records, evidence boundaries, permission changes, and recourse paths.

The customer value is simple: cross-agent work should not erase accountability. It should create better records.

What builders should avoid

Do not let remote agents inherit local credentials by convenience. Do not treat agent identity as equivalent to organization identity. Do not accept capability cards as proof of safe authority. Do not store only the final answer when the delegation path is the real security artifact. Do not let recertification depend on human memory.

Most importantly, do not describe cross-agent failures as "unexpected behavior" when the system never preserved the authority chain. If the authority chain is missing, the security model was incomplete before the incident began.

FAQ

Does A2A solve agent trust?

No. A2A helps agents communicate and interoperate. Trust still requires identity, evidence, permission, recourse, and consequence logic around the interaction.

Does MCP make tool use safe by default?

No. MCP standardizes connection patterns. The Agentic OS still needs tool-specific permission, receipt, and review policy.

What should builders implement first?

Implement delegation receipts for cross-agent work before expanding tool authority. Preserve who delegated what, to whom, under which evidence, with which recourse rule.

The delegation test

The cross-agent future will not be secured by connectivity alone. The Agentic OS security model has to make delegation inspectable, authority narrow, evidence fresh, and recourse unavoidable.