An architecture for secure agents needs to limit what each identity can do, verify conditions at the point that executes the action, and record how the result was confirmed. Start with an operation with a defined scope: connecting the model alone does not establish control over the tools and systems the agent uses.
Where should control take place?
Map the path between request, agent, model, tool, and target system. Identify who maintains each component and which alternative paths exist. If the agent can use a credential directly against the financial system, a control placed only at model access does not receive that call. The map needs to reveal this path before claiming that the operation is covered.
Separate the decision suggested by the model from the technical authorization to execute it. The integration should check identity, resource, operation, and relevant business conditions before the change. The instruction “do not exceed the limit” in a prompt guides behavior, but it is not equivalent to a permission enforced by the system receiving the action. The design should make explicit what will be checked at each integrated point.
How do you integrate existing agents without starting from scratch?
Inventory the agents and tools involved in the chosen operation. For each tool, record input, output, authentication, possible effects, and owner. The team can start by connecting a critical point, such as writing to a record, without replacing all agents. This scope should remain visible: integrating one tool does not prove coverage of the others.
Agree on output contracts and states that the team can interpret. A ready proposal, a granted authorization, a submitted attempt, and a confirmed result are different events. When human approval is required, the integration needs to link the decision to the parameters that will be executed; changing the amount or recipient after approval should trigger a new check. The contract also needs to represent the absence of confirmation.
What should you do when a tool does not respond?
A response that has not arrived leaves uncertainty: the system may have made the change. Retrying immediately may duplicate the work. Define how to query the state in the target system, link attempts to the same operation, and decide when a person should intervene. The policy depends on the integration and its guarantees; an error code alone does not convey the full business state.
Recovery needs to be part of the initial design. Specify how to handle unavailability, retries, delayed responses, and partial confirmation. When an operation involves multiple items, such as different medical tests, confirmation of one item does not confirm the others. If the system does not offer a reliable way to check the change, record the limitation and reduce autonomy until a follow-up path exists.
How do you validate before expanding use?
Build representative scenarios with inputs and environments appropriate for testing: an allowed action, a blocked action, incomplete data, expired approval, a change after approval, an unavailable integration, and a duplicate response. For each scenario, describe the expected effect in the target system and what the team should be able to observe. A test that checks only the text of the agent’s response does not validate the integration.
Release a limited scope with defined owners and a rollback path. Compare the new version using the same criterion and record what was not tested. A version that works with human review still needs its own assessment before receiving permission to execute automatically. At Starya, this design connects engineering, NebulaOS, and work monitoring; the actual scope depends on the deployment’s integrations.
Illustrative example · no customer data
A record update with an unknown result
Fictional example: the agent proposes updating an address. The integration checks permission and submits the change, but the response does not arrive. The conversation cannot present this attempt as confirmed completion.
The flow queries the record using the authorized identity. If it confirms the change, it closes the outstanding item; if it finds another state or cannot query the record, it routes the item for investigation before retrying. The goal is to preserve continuity without inventing certainty about the result.
When the approach needs to change
When the integration allows only reading, limit the first delivery to preparing proposals. When reliable confirmation is unavailable, retain human verification and an explicit pending state. Choosing a smaller scope may be the condition for operating responsibly while the dependency is resolved.
A point to watch: Treating the model gateway as automatic coverage of all the agent’s tools.
The worksheet is ready to move forward when…
- The map identifies read and write paths and their owners.
- Permission, approval, and execution are linked to the same parameters.
- Failure, partial completion, and an unknown result have defined handling and tests.
Use the roadmap to review a real integration. Then compare the needs with the components and controls available in the deployment.
Your worksheet
Complete it with your team.
Record what you know and what still needs confirmation. Answers stay in memory and are not submitted.
References for further reading
- OWASP — Agentic AI: Threats and Mitigations ↗
A reference for modeling threats to agent systems and discussing mitigations. The roadmap and scenarios below are Starya working proposals, not a full reproduction of the document.
- RFC 9110 — idempotent methods ↗
HTTP semantics help frame the discussion of repeated requests. A business operation still needs to define deduplication and reconciliation with the target system.