Technical architecture and control design for enterprise applications

AI agents can authenticate correctly and still perform actions that violate a business control. A procurement agent might change a supplier bank account, pass work to a second agent, and trigger a payment through another application. Security, finance, and audit teams need a defensible answer to the same question: What did AI agents actually do after authorized access?

aiFObserve provides a foundation for that answer by combining normalized AI sessions, usage and cost analysis, behavioral risk signals, custom rules, and evidence exports. Connecting those observations to identity and business transaction records can turn an isolated AI session into a reviewable account of who acted, under whose authority, on which object, with what outcome.

The control objective

For an AI assisted process that affects financial reporting, the control objective is to identify and investigate activity that could undermine authorization, separation of duties, transaction integrity, or the reliability of supporting records. Management determines the relevant risks and controls; the auditor evaluates the evidence. The SOX connection follows the financial process and affected assertions, rather than the presence of AI alone. [1, 2]

This architecture describes both the existing analytics foundation and the integration work required for full agent transaction assurance. The current framework reporter covers 11 named frameworks; SOX is not currently a named report. Full cross application SoD detection must be implemented and validated against business events before it is offered as an operating control.

Architecture for authorized access and subsequent activity

Use an event collection layer to preserve application actions alongside the existing session analytics pipeline. Transaction history must remain available at event level because a session total cannot establish the order of a master data change, approval, and payment.

A minimum event contract

Retain event ID, tenant, application, UTC event and ingestion times, actor ID, agent ID, delegated principal, agent run ID, trace and parent span IDs, action, target object, before and after values or protected references, result, and correlation confidence. For financial workflows also capture transaction amount and currency, approval ID, approver, approval scope and time, legal entity, and business process ID. These business fields require schema and loader extensions; they are not all native normalized session fields today.

Keep sensitive content in an appropriately controlled source repository where possible. Use references or redacted values in analytics. Model prompts, payroll data, bank details, and audit workpapers need access restrictions and retention policies aligned to the organization.

Sources and correlation determine the quality of the answer

Use explicit relationships before proximity

Join within the same tenant and environment using an application transaction ID, trace or run ID, or verified delegation relationship. A common IP address and close timestamps are weaker evidence, especially behind proxies and shared service accounts. Keep uncertain matches separate and show the matching keys and confidence to reviewers. A trace ID can be reused or supplied by a client, so tenant and source validation still matter.

Preserve contradictions and missing coverage

Record both the attempted tool call and the application result. A gateway allow decision proves permission at that point; an ERP commit proves a business change. A timeout does not prove that a transaction failed. Record late events, clock skew, collection outages, and unlinked actions. Missing approval evidence is a review condition until the approval source and collection completeness have been checked.

The inspected v2 session correlator retains correlation metadata and applies maximum values to selected numeric fields when combining overlapping observations. That supports session enrichment. Financial transaction counts, provider charges, and ordered business actions still need event specific reconciliation and authoritative source rules.

Worked example of cross application separation of duties

Illustrative scenario: an agent processes a supplier payment across a procurement system, an ERP, and a treasury service. The control prohibits the same accountable principal or delegated agent chain from both changing bank details and releasing payment to that supplier without a separate, valid approval.

The detection logic

Resolve the initiating principal and verified agent delegation chain. Find a committed bank detail change and a committed payment against the same supplier and legal entity within the policy window. Establish whether the payment used the changed details. Check for an independent approver whose approval covered the relevant change, payment, and timing. Apply approved exceptions and reversals. Emit a potential SoD violation when the prohibited relationship is established and no valid independent approval is present in a complete approval dataset.

An example window of 24 hours is a test parameter, not a universal control requirement. Identity matching must account for agents using separate credentials under the same principal and avoid merging unrelated agents with a common platform owner. A legitimate shared owner may require additional role and process evidence before a conflict is concluded.

What the reviewer receives

The proposed evidence package contains the event timeline, delegation links, supplier and payment references, change version, amount, control and rule versions, matching keys, approval search result, collection coverage, and exception rationale. It distinguishes a confirmed transaction relationship from an inferred actor relationship.

Current custom rules evaluate individual enriched records and consolidate repeated matches. Consolidation does not establish ordered actions across applications. This scenario requires an additional stateful evaluator and event model, or a trusted upstream service that computes and supplies the required transaction relationships.

ERP and enterprise application risk coverage

Prioritize scenarios by financial exposure, autonomy, transaction reversibility, and evidence availability. The following examples describe control designs for an integrated deployment; application names identify target event sources, not prebuilt native aiFObserve connectors.

Separate risk signals from business violations

aiFObserve can already flag supported network and session patterns such as unauthorized AI access, suspicious volume, exfiltration patterns, connection anomalies, or cost amplification when the relevant fields are present. An anomaly is a reason to investigate. It does not by itself establish fraud, an incorrect accounting entry, or a material weakness.

Tool error spikes and abnormal request or response patterns can support an investigation into prompt injection or tool abuse. A conclusion that an injected instruction caused a payment requires instruction or tool evidence linked to the business action. Aggregate tool counts cannot reveal which ERP operation was executed.

Behavioral analytics and economic accountability

observed behavior at the right level

The available analyzers summarize sessions, providers, applications, users, time patterns, blocks, tool counts, cache behavior, and cost concentration. These metrics help reviewers find unusual growth, repeated retries, unapproved destinations, and activity outside expected operating periods. Interpret time patterns in the relevant business timezone and distinguish service accounts from people.

Keep cost estimates and realized value distinct

The current cost suite uses a static pricing model and can derive tokens from network bytes. Native provider token counts improve measurement, but negotiated prices, cache discounts, batch rates, GPU commitments, and tool charges still require reconciliation. Compare modeled cost with invoices before treating the result as financial spend. Projection ranges are planning scenarios, not statistical confidence intervals.

ROI requires business outcome evidence. A useful integrated measure is cost per successfully completed, policy compliant case. Add accepted output, completion status, measured handling time, and rework before claiming realized savings. Token volume and an assumed value per megabyte cannot establish business benefit on their own.

Privacy and geographic evidence

Use provider region, declared residency, allowed regions, cross border indicators, and source confidence to identify boundary exceptions. IP geolocation does not prove where a provider stored or processed data. Classification, contract terms, lawful basis, and retention commitments require evidence from the relevant organizational systems.

Evidence for SOX controls and audit review

SOX Section 404 concerns management assessment of internal control over financial reporting. Applicability of auditor attestation depends on issuer requirements and exemptions. aiFObserve can support control monitoring and evidence preparation; a framework report or risk score does not constitute an audit opinion. Management and the auditor determine how evidence supports their conclusions. [1, 2]

Build an evidence package that can be challenged

Available CSV exports cover evidence summaries, field coverage, provider locations, data boundaries and control mappings; incidents also retain triggering session details. Extend the package with a control ID, period, scope, versioned rule, event timeline, source manifest, reviewer disposition, and remediation reference. Keep a completeness reconciliation and identify the population from which a reviewer selects items.

The source manifest should link preserved event records to the export and record transformations, exclusions, deduplication, time handling, and late arrivals. Integrity hashes, immutable storage, access history, and retention enforcement should be provided by a governed evidence repository and integration workflow; they should not be assumed to exist because a CSV was produced.

PCAOB AS 1105 addresses sufficient appropriate evidence and the reliability of information used in an audit, including accuracy and completeness considerations for company produced information. Reconcile exporter totals to source populations and test field transformations before relying on analytics in a control review. [3]

Deployment plan and proof of control value

Start with a bounded business process such as supplier changes and payments in one legal entity. A practical pilot combines the available v2 analytics with the event and control extensions required for that process. Set the operating cadence from the control objective and measured ingestion delay; the file based pipeline alone is not a guarantee of continuous or real time coverage.

Measure ingestion completeness, action attribution, transaction linkage, approval coverage, false positives on adjudicated cases, missed seeded conflicts, event to finding delay, and time to assemble a review package. Agree thresholds before the pilot. For example, report attributable actions divided by observed in scope actions together with source completeness, because a high attribution rate on an incomplete population can mislead.

Current module responsibilities

The inspected v2 runner invokes usage, cost, ROI, projection, trend, security, recommendation, and optional custom rule and framework reporting functions after normalization. The shared ai_identity_resolver.py resolves AI provider and application identity; it is not an agent delegation graph. The SOX transaction model, application adapters, ordered SoD evaluator, approval validation, and governed evidence workflow are additional implementation work.

Sources and technical basis

Product basis: current v2 runner, normalized schema and loader, custom rule evaluator, security analyzer, cost and trend documentation, compliance evidence builder and framework reports, plus the v2 session correlator and OTLP converter. Inspection date 14 October 2026. Script names are given without installation paths.

[1] SEC Staff Statement on Management's Report on Internal Control Over Financial Reporting. https://www.sec.gov/info/accountants/stafficreporting.htm

[2] PCAOB AS 2201 An Audit of Internal Control Over Financial Reporting. https://pcaobus.org/oversight/standards/auditing-standards/details/AS2201

[3] PCAOB AS 1105 Audit Evidence. https://pcaobus.org/oversight/standards/auditing-standards/details/AS1105

Reference pages checked 14 October 2026. AS 2201 lists amendments effective 15 December 2026; apply the version relevant to the engagement period.