An agent can move a case across systems, while every action still receives an independent authorization decision.
The agent stores no system credentials. For every intended action, it sends the full context to a decision point. Only an approval releases the appropriate credential. A denial prevents the target-system call and records the governing rule.
Verified demonstration scope
The system prepared an action request in an agreed format. A separate control made the binding decision, required a second approval, and did not call the target system.
- Recorded test
- Verified demonstration scope
- What we tested
- Agent action controls
- Measurement data
- test data
Problem, solution, and result
Why a shared agent account creates risk
A process crosses ERP, CRM, and DMS, each with different roles and credentials. A permanent agent key makes individual actions hard to limit and explain after the event.
What the system does
Before each action, the system checks identity, business unit, data class, action type, reversibility, and required approvals. A denial blocks access to credentials and prevents any call to the target system.
What we tested
The system prepared an action request in an agreed format. A separate control made the binding decision, required a second approval, and did not call the target system.
For whom
This fits an organization that wants agents to work across systems while retaining per-action controls, separation of duties, and a complete audit trail.
Request → policy → credential → audit
- 01The agent stores no system credentials
- 02Every action gets a separate decision
- 03A denial stops the call before the target system
- Best for
- Multi-unit organizations with agents working across several systems
- Decision input
- Agent-proposed actions in ERP, CRM, and DMS, each carrying identity, data class, and reversibility
- Human decision
- Policy owners approve roles, exceptions, and actions requiring a second authorization
- Cost
- About PLN 0.0032 for the recorded action request; a separate control makes the binding decision.
- Security
- A disallowed action is stopped before any ERP, CRM, or DMS call. A high-risk action requires a second approval.
- Test scope
- We measure decision time in a pilot using the client’s rules, systems, and expected load.
- Audit trail
- Every decision retains the applied rule, its version, the executor, and required approval.
- Similar system build
- from €6,000 net (approx. $6,500) · 6–16 weeks
Authorization boundary
Who owns permissions
System and security owners approve roles, policies, and exceptions. Actions requiring a second approval wait for a person. The agent can execute only what the current policy allows.
- Cost
- About PLN 0.0032 for the recorded action request; a separate control makes the binding decision.
- Security
- A disallowed action is stopped before any ERP, CRM, or DMS call. A high-risk action requires a second approval.
What production still requires
The demonstration recreates the mechanism with a fictional company and mock ERP, CRM, and DMS systems. It does not expose the client's private topology. Deployment requires mapping the client's roles, data classes, separation-of-duty rules, and credential flows.
Estimated impact
Calculate the impact at your volume
This estimate uses the stated volume. Enter your own numbers to assess the possible impact in your company. The result is confirmed only during a pilot.
Today
Modelled current scenario: 38 h
With the system
Modelled after scenario: 12 h
Time or cost saved
Modelled scenario: 18-35 h/mo, base 26 h
- Volume
- Modelled scenario: 900 actions/mo
- Formula
- 900 x (2.5 - 0.8) min / 60
- Calculation status
- medium
Data in the screenshots. The names, amounts, and documents shown in the screenshots are synthetic. Client data remains private. Measurements describe the demonstrator and are kept separate from production outcomes.
Working views
System owners set policies and exceptions. The agent moves the case only within the approved scope.
A case can cross several systems without manual handoffs. Every action has its own decision and reason. Security can reconstruct the path without giving the agent permanent access.
Decisions, policies, and the case trace.
Context test
A decision for a specific identity, unit, data class, and action.
Policy register
Roles, owners, rules, and required approvals.
Audit trace
Decisions and calls across ERP, CRM, and DMS.
System screens
See how the system works in practice
These desktop and mobile screenshots come from the running application. They show the process and the points where a person makes the decision.
- Screens
- 12
- px
- 1440 · 390
- 021440×1100
Role and access-policy register. - 031440×1100
Case history across three systems.
Open the remaining screen archive (9)
- 041440×1100
Cases - 051440×1100
A case and its access matrix - 061440×1100
Runs - 071440×1100
A stopped execution - 081440×1100
Permissions - 091440×1100
Policy rules - 101440×1100
Separation of duties - 111440×1100
Audit ledger - 121440×1100
Measurement
Technology stack
The policy engine sits outside the agent, because that boundary is the product here.
LangGraph runs the process loop, but the agent is treated as an untrusted client: permissions are settled by OPA as a separate service, and identities and roles are policy data. A rule can therefore be read, tested, and changed without touching agent code, and the audit receives the rule version with every decision. The three fictional targets authenticate with three different mechanisms, so the credential separation is visible in practice. In maintenance the policy changes the way code does: by review and version.
- OPA 1.8.0
- an independent decision point: evaluates every request and returns the decision with its rule and policy version
- LangGraph 1.2.10
- runs the process loop as an untrusted client, with no access to target credentials
- Dex 2.43.1
- a local OIDC identity source; its Bearer token authenticates the CRM adapter, so the third access mechanism is implemented
- FastAPI + httpx
- the target adapters: authenticate ERP, CRM, and DMS with three different mechanisms, only after a permit
- PostgreSQL 17
- an append-only decision log with an entry-integrity test
The client takes over the code, the policy rules, the evaluation data, and the documentation. The reference implementation runs as six Docker Compose services on generated test data and touches neither client data nor client credentials.
Technical details and measurements
How the system works
Authorization comes first. Credentials and execution follow only after approval.
The workflow chooses the next step. A separate policy decision point checks whether this identity may perform this action on this data class. The adapter retrieves a credential only after approval.
The agent submits an action with full context
The policy engine checks rules and approvals
Approval releases the right credential
Denial stops the call before the target system
Decision, execution, and reason enter the audit trail
System architecture
A process graph, a decision point, separate identities, and an audit.
The process loop runs in a graph, but permissions are settled by an external policy engine. Every target system has its own tool identity, and every decision lands in an append-only log.
- 01
Context
The request carries the decision's full context.
The identity, the organizational unit, the data class, the action, its reversibility, and the required approvals travel with the request. The policy rules on what the request carries, without reaching into the agent's state.
- 02
Decision
OPA answers before every tool.
The decision point evaluates the full set of denial rules in one pass and returns permit, deny, or a second-signature requirement, with the reason and the rule version. The rules are code: readable, testable, versioned.
- 03
Identities
Every system has its own credential.
The ERP authenticates with HTTP Basic, the CRM with an OIDC token, and the DMS with HMAC, so the separation of identities is visible in practice. After a denial, the adapter sends no credential and never calls the target.
- 04
Audit
An append-only log with verified integrity.
The target system, the tool identity, the executor, the decision, and the reason go into the log, and an integrity test catches an edited entry.
Why the policy lives outside the agent
Permissions written into a prompt vanish with the first clever workaround. The separate policy engine is the one piece of this stack beyond the minimum, and it defends itself: a rule can be read, tested, and changed without touching the agent, and every decision leaves proof. Complexity that cannot defend itself like that would not have made it into the system.
- A policy decision precedes every tool call
- The rules are code outside the agent's application
- After a denial, the adapter sends neither a credential nor a call
- A human's second signature guards irreversible actions
Want to assess a similar process in your company?
- A 30-minute call with the engineer who would lead the work.
- A review of the processes that cost you the most time and money.
- A written summary of what to automate first and the likely cost range.
Times are shown in your own time zone. We work with clients across time zones.
The scan is free and creates no obligation. If automation is unlikely to pay off, the written recommendation will say so.