No Journal Postings at 3am

An AI agent that calls execute_journal during normal finance operations may be doing exactly what it was designed to do.

The same agent making that call at 3am on a Saturday deserves a different response.

The tool is unchanged. The arguments may be valid. The agent’s identity may be verified, and the request may be within its rate limit.

Even so, the call may be inappropriate because of when it is happening.

Tool Access Is Only Part of the Control

Most discussions about AI agent security focus on which tools an agent is allowed to call.

That is necessary, but it is not sufficient.

A finance user with access to the general ledger is not necessarily permitted to post journals at any time. Organisations often define operating hours, maintenance windows, approval periods, and escalation arrangements for higher-risk activity.

Those controls exist because context matters. A transaction carried out during normal business hours, when finance staff are available to review exceptions, is different from the same transaction taking place overnight with no immediate oversight.

AI agents need the same kind of boundary.

An agent may have a valid identity and permission to use a tool, but that does not mean the tool should be available at every hour of every day.

Timing Is Part of the Risk Decision

Control frameworks associated with SOX-regulated financial processes commonly place importance on controlled changes, defined responsibilities, and evidence that sensitive activity takes place within an approved process.

The same principle can be applied to agent activity.

If an agent posts journal entries, the organisation may reasonably decide that postings should occur when the finance team is available to review them. If an agent modifies customer records, the organisation may prefer those changes to happen when operational and security teams can respond to anomalies.

FCA and PRA operational resilience expectations approach the issue from a broader perspective. Regulated firms are expected to understand their important business services, define tolerances, and manage the operational risks that could disrupt them.

The precise application will depend on the organisation and should be assessed with appropriate compliance and legal input. However, an agent operating without any time-based restriction may be harder to reconcile with a clearly defined operating model.

The question is not only whether the agent is authorised. It is whether the action is taking place under the conditions the organisation considers acceptable.

Rate Limits Solve a Different Problem

Rate limits and time windows are sometimes discussed as though they provide the same control.

They do not.

A rate limit controls volume. It might allow:

• Ten calls per minute
• One hundred calls per hour
• One thousand calls per day

This helps prevent runaway loops, accidental repetition, and excessive load on backend systems.

A time window controls availability. It might allow a tool to run:

• Monday to Friday
• Between 09:00 and 17:00
• In the Europe/London time zone

An agent making a single call at 3am is unlikely to breach a rate limit. That does not make the call appropriate if it posts a journal, changes permissions, or initiates a payment.

Many higher-risk tools need both controls. Rate limits constrain how often they can be used. Time windows constrain when they can be used.

What Time-Windowed Access Looks Like

Within the gateway, a tool policy can include an AllowedHours block defining the permitted days, start time, end time, and time zone.

"AllowedHours": {
  "DaysOfWeek": [
    "Monday",
    "Tuesday",
    "Wednesday",
    "Thursday",
    "Friday"
  ],
  "StartTime": "09:00",
  "EndTime": "17:00",
  "TimeZone": "Europe/London"
}

A call made outside that window is rejected with a structured reason:

DenyReason.OutsideAllowedHours

The decision is also recorded in the audit trail.

This gives the agent a clear result. The request was not rejected because its identity was invalid or because the tool was unavailable. It was rejected because the request fell outside the approved operating period.

Time windows can also span midnight. For example:

"AllowedHours": {
  "DaysOfWeek": [
    "Monday",
    "Tuesday",
    "Wednesday",
    "Thursday",
    "Friday"
  ],
  "StartTime": "22:00",
  "EndTime": "06:00",
  "TimeZone": "Europe/London"
}

That might be appropriate for a tool designed to run only during an overnight batch-processing window.

The important point is that the permitted schedule reflects the purpose and risk of the tool.

Evaluate Time Before Rate Limits

The order of policy evaluation also matters.

A request made outside the permitted time window should be denied before it consumes a rate-limit allowance.

Otherwise, repeated out-of-hours attempts could reduce the agent’s available quota even though none of the calls was eligible to proceed.

Evaluating the time policy first produces a cleaner result:

1. The gateway checks whether the tool is currently available.
2. An out-of-hours request is denied.
3. The rate-limit quota remains unchanged.
4. The agent retains its allowance for the next valid operating window.

This keeps two separate controls from interfering with one another.

Different Tools Need Different Schedules

A single agent may use several tools, but those tools do not all need the same operating hours.

For example:

• get_account_balance may remain available 24 hours a day because it is read-only and useful for overnight monitoring.
• execute_journal may be limited to business hours so finance staff can review unusual activity.
• modify_access_control may be restricted to specific change windows that align with the organisation’s approval process.

The route, identity, and agent can remain the same. The policy changes according to the risk and purpose of each tool.

This is more precise than applying one schedule to the entire agent. It allows low-risk operations to continue while placing tighter controls around actions with greater financial, operational, or security consequences.

Define When, Not Just Whether

Tool allow lists answer an important question:

Is this agent permitted to call this tool?

Time-windowed access answers another:

Is the agent permitted to call this tool now?

For sensitive operations, both questions matter.

If an AI agent posted a journal entry at 3am last Saturday, would your controls prevent it, record it, or alert someone who could respond?

Learn more about the MCP Audit and Compliance Gateway