How audit logs and observability enforce hard limits on trading agents

Felix uses a split-execution architecture where every intent from a trading agent is checked against hard limits before it reaches any venue. The same path writes a tamper-resistant audit log that records the intent, the limit check, and the outcome. This makes the agent's behavior fully observable and prevents the agent, the infrastructure, or an external tool from silently overriding the constraints.

What happens when an agent tries to trade outside its limits?

When an agent connected to Felix submits an order intent, the request does not go directly to a stock broker, a perps venue, an options venue, or a prediction market. Instead, it enters a validation layer that evaluates the intent against the owner's configured constraints. These constraints include budget caps that count total exposure across all five market types, position limits that restrict how large a single position can become, and drawdown thresholds that halt trading when losses reach a predefined floor. The limits are hard in the sense that the agent itself cannot modify them, and the infrastructure that enforces them cannot bypass them on behalf of the agent.

Suppose an agent has a budget cap of ten thousand dollars and already holds eight thousand dollars in exposure across two prediction markets and a crypto perpetual. If the agent generates a new intent for a three thousand dollar equity position, the validation layer sees the total would exceed ten thousand dollars and rejects the equity order. The agent cannot override this by splitting the equity order into two smaller tickets, because the layer counts the aggregate notional value within a rolling window. The rejection is immediate, and the reason is recorded in the audit log. The owner can review these rejections to understand whether the agent is generating flawed signals or approaching its boundary conditions. This is important because trading can lose money, including everything, and a rejected order is often preferable to an order that breaches a safety boundary.

The validation layer also normalizes the order size into plain US dollars, as the Felix API abstracts away venue-specific contract math. This means the audit log shows a consistent unit of account regardless of whether the agent traded a crypto perpetual, an equity, or a prediction market outcome. The owner does not need to decode notional values, tick sizes, or margin requirements to verify that the agent stayed within its dollar-denominated budget. The normalization happens before the limit check, so the log always reflects the intended economic exposure rather than the raw contract quantity.

How does the audit log architecture prevent silent failures?

An audit log is only useful if it is complete and resistant to tampering. Felix stores the audit trail outside the agent's control, so a compromised or misbehaving agent cannot delete, modify, or truncate its own history. Each entry contains a timestamp, the agent identifier, the intent, the limit-check result, and the final disposition. The sequence is append-only, and the system uses internal integrity checks to detect gaps or out-of-order writes. If an entry is missing, the pipeline halts until the gap is resolved, which prevents the agent from hiding a failed or unauthorized order.

Silent failures are a common risk in automated trading. Suppose an agent repeatedly sends orders that are just below a position limit, but a rounding error or venue-specific fee pushes the actual exposure over the edge. Without a unified log, the owner might only discover the breach after reviewing external statements. The Felix audit log captures the intent and the exact limit state at the moment of evaluation, so the owner can reconstruct whether the breach originated from a bad limit calculation, a stale market data feed, or an unexpected fee. This visibility is especially valuable when starting an AI trading agent with hard limits because it lets the owner verify that the constraints are actually engaged.

The log also records configuration changes. When an owner updates a budget cap, adds a new scoped key, or modifies an exit plan, the change is written as a separate audit entry with a reference to the previous state. This creates a timeline that links agent behavior to the rules that were active at that exact moment. If an agent suddenly stops trading, the owner can check whether the halt was caused by a limit breach, a key revocation, a manual panic command, or a scheduled change in scope. The log therefore serves as both a debugging tool and a historical record of compliance with the owner's own risk policy.

Where does observability live in the execution path?

Observability in Felix is not a sidecar that watches from a distance. It sits in the critical path between the agent and the venue. Every intent generates a telemetry event at the moment it is received, a second event after the limit check, and a third event after the external response returns. These events feed into a stream that the owner can query to see live exposure, pending orders, and recent rejections. The events are ordered by the same sequencing mechanism that governs the audit log, so the observability view and the audit trail are always consistent.

Because the system normalizes orders into US dollars, the observability dashboard shows a single, coherent view of capital at risk across stocks, crypto, perps, options, and prediction markets. The owner does not need to log into separate interfaces to add up exposure. The telemetry also includes latency measurements between the validation layer and each venue, which helps the owner spot whether an agent is trading on stale prices or experiencing abnormal execution delays. If the latency for a particular venue spikes, the owner can pause the agent's access to that venue without disabling the agent entirely.

This design means that observability is fail-closed. If the telemetry pipeline breaks, the execution path halts rather than continuing blindly. The owner is notified through the same event stream, and the agent cannot submit new orders until the observability layer confirms it is healthy again. This is a deliberate trade-off. It prioritizes safety over uptime, which aligns with the principle that developers should set spend caps and drawdown limits and then verify that those limits are being enforced in real time. An agent that cannot be observed is an agent that cannot be trusted with hard limits.

Why are scoped keys and kill switches part of the same audit trail?

A scoped API key defines what an agent is allowed to do before it ever sends an order. The scope might restrict the agent to a single market type, a maximum order size, or a specific set of trading hours. When the key is created or rotated, the audit log records the scope, the creation time, and the owner authorization. This means the owner can later prove that an agent was never permitted to trade instruments outside its scope. If the owner rotates a key because the old one was used in a testing environment, the rotation itself is logged, and the old key is permanently invalidated.

The kill switch, or panic command, is the inverse of a scoped key. It is an owner-initiated revocation that flattens positions and disables the agent's access. When triggered, the audit log records the command, the positions that were closed, the venues that received the flatten orders, and the final confirmation that the key was revoked. Because the kill switch is also subject to the same logging pipeline, it cannot be suppressed by the agent or by a failure in the agent's host environment. Even if the agent's server loses power, the kill switch command is already in flight and will be executed by the infrastructure.

Together, scoped keys and kill switches form the boundary of the audit trail. The log begins with the key's scope and ends with either normal operation within those bounds or an emergency halt. This continuity is essential for owners who automate exit plans and take profits while keeping custody because it proves that the exit plan was executed under the owner's original constraints. Even if the agent is running inside an AI code editor through an MCP connection, the audit trail remains independent of that editor's state. The editor may crash, but the log persists, and the kill switch remains actionable.

How should developers interpret agent telemetry before going live?

Before authorizing live trading, developers should inspect the audit logs and telemetry generated during paper trading with the same rigor they would apply to a production system. The paper trading environment uses the same validation layer and the same observability pipeline as live trading, so rejections, latency spikes, and limit breaches in testing are meaningful signals. If an agent hits a budget cap repeatedly during paper trading, the owner should treat that as a design flaw rather than a testing artifact. The agent is showing that its signal generation is not respecting the economic boundaries that will be identical in live mode.

Developers should look for three patterns in the telemetry. First, check the rejection rate. A high rate of limit rejections suggests the agent's signal generation is poorly aligned with its constraints. Second, review the latency between intent and confirmation. Large or increasing delays may indicate that the agent is sending orders during periods of low liquidity or that the normalization layer is struggling with venue-specific sizing. Third, examine the drawdown trajectory. Even in paper trading, a steep drawdown that triggers a halt reveals that the agent's risk profile is incompatible with the owner's limits. These patterns are easier to spot when the telemetry aggregates all five market types into a single USD view.

The exact request schema is in the docs; the shape looks like this for pulling recent audit events via a generic REST interaction:

curl -H "Authorization: Bearer YOUR_KEY" \
     -H "Content-Type: application/json" \
     -d '{"agent_id":"your_agent","limit":50}' \
     https://api.example.com/v1/audit/stream

Replace the placeholder values with your actual credentials and agent identifier. The response returns a paginated list of intent, check, and outcome records that you can feed into your own dashboard or alerting system. Developers who run their first trading agent from an AI code editor using MCP can also query these events through the same tools they use to send orders, keeping the feedback loop tight.

Going live requires explicit owner authorization of a key, and the telemetry should be the basis for that decision. If the logs show clean execution within limits, stable latency, and no unexpected drawdown breaches, the owner can authorize the key with confidence. If the logs are noisy or ambiguous, the owner should extend paper trading until the agent's behavior is predictable. Trading can lose money, including everything, and telemetry is the only way to verify that an agent respects its boundaries before real capital is at risk.

The audit log is not merely a record of what happened. It is the evidence that the hard limits are working as intended.