Stay connected: follow us on LinkedIn and explore more at
www.CherryHillAdvisory.com.

Subscribe now to join the Risk Register community:

Source: GlobeNewswire (Darktrace press release)
Summary: Darktrace introduced Signal Labs, a research program dedicated to behavioral security risks from enterprise AI agents. The initiative will study unintended agent behaviors and agentic attack surfaces, and publish research and tooling to detect and characterize anomalous agent actions. Signal Labs is positioned to complement Darktrace’s behavioral security products and will focus on agent alignment, auditing, and new telemetry for autonomous systems. No pricing or product availability changes were announced. For internal audit, this is a new source of evidence and methods for identifying emerging risks in AI-enabled workflows.
How Internal Audit Can Deploy This: Treat Signal Labs as a standing intelligence feed for your risk assessment and continuous monitoring. First, map the failure modes and anomalous behaviors identified by its research into your risk register under operational risk and IT risk. Tie each behavior to owner systems (agent platforms, RPA+LLM combinations) and to existing controls (approvals, guardrails, isolation). Second, use Signal Labs’ published tooling where applicable to run full‑population analytics on agent activity telemetry (events, prompts, actions) to spot drift or unintended actions in high‑impact processes (e.g., AP triage, customer communications, access provisioning). Third, add agent alignment checkpoints to control testing: verify that triggers for human-in-the-loop, rate limits, and permission scopes activate when an agent attempts an out‑of‑policy action. Concrete use cases: - Continuous monitoring: subscribe to Signal Labs indicators and test them against production agent logs to detect emerging risks before incidents escalate. - Control testing: for a finance agent that drafts journal entries, test whether misalignment signatures produce holds and approvals before posting (ICFR relevance). - Evidence gathering: capture anomalous agent events flagged by tooling as workpapers, citing specific telemetry fields. Pilot this quarter: select one business agent with accessible telemetry; obtain read‑only event exports; run the Signal Labs detection heuristics; review top 10 anomalies with the process owner; refine thresholds; document resulting changes to your risk assessment. Safeguards: operate read‑only; minimize data copies; mask PII in exports; restrict access to the audit sandbox; require human review of all anomalies; align with your AI governance policy on model/agent auditing and disclosure to owners.
✎ Try it yourself — Checklist
Checklist — Put Darktrace Signal Labs to work in audit (pass/fail) 1) Intake and classification - Confirm subscription to Signal Labs research/tooling updates is active (Pass/Fail) - Extract the latest taxonomy of unintended agent behaviors and attack surfaces (Pass/Fail) - Map each behavior to entries in your risk register with owner, likelihood, and impact noted (Pass/Fail) 2) Telemetry readiness - Identify one enterprise AI agent with exportable activity telemetry (events, prompts, actions) (Pass/Fail) - Verify read-only access to telemetry and storage in an audit-controlled workspace (Pass/Fail) - Ensure PII masking and access controls are applied per AI governance policy (Pass/Fail) 3) Detection deployment - Load Signal Labs’ published detection rules/heuristics into your analytics workflow (document version/date) (Pass/Fail) - Run against a full population from the last 60–90 days; retain immutable results (Pass/Fail) - Validate top anomalies with system owners; classify as true/false positives with rationale (Pass/Fail) 4) Control evaluation - For each confirmed anomaly, trace to a specific control (guardrail, approval, isolation) and test if it activated (Pass/Fail) - Document control gaps and proposed remediation owners/dates (Pass/Fail) 5) Reporting and governance - Update the risk assessment with observed emerging risks and residual risk ratings (Pass/Fail) - Store evidence (telemetry slices, rule configs, owner sign-offs) in workpapers with citations (Pass/Fail) - Schedule quarterly refresh aligned to new Signal Labs publications (Pass/Fail)

Source: Oracle Newsroom
Summary: Oracle announced Fusion Claw, a governed agentic execution runtime for Oracle Fusion Agentic Applications. It blends AI reasoning with deterministic enterprise computation to execute complex, multi‑step business work. Oracle also highlighted AI Agent Studio for creating, extending, and managing agents that use trusted enterprise data, with built‑in security, data governance, and performance controls. Fusion Claw is part of the Fusion Applications stack and generally available to Fusion customers; pricing was not provided. For audit, this concentrates automated execution inside ERP with governance hooks auditors can test.
How Internal Audit Can Deploy This: Start by inventorying agentic workflows in Fusion Applications and tagging those relevant to ICFR and SOX compliance. Focus on processes where agents execute or orchestrate business work (e.g., approvals, configurations, postings). Obtain read‑only access to Fusion governance views for Fusion Claw and the Oracle AI Agent Studio to review configurations without deploying or changing agents. Use cases: - Control design and testing: Confirm that governance controls (e.g., scoped data access, performance limits, approval checkpoints where configured) are enabled for high‑risk agent tasks. Trace agent actions to control objectives and verify evidence of execution and hold/approve steps. - Segregation of duties: Assess whether agent service accounts and their entitlements violate SoD rules. Test that agent‑initiated changes cannot self‑approve downstream steps. - Change governance: Review creation/extension activities in Agent Studio for proper approvals, testing notes, and migration evidence before agents operate in production. Pilot this quarter: select one end‑to‑end workflow (such as procure‑to‑pay) where Fusion Claw agents are active. Export agent run metadata from governance views for the last 60 days. Sample exceptions where runtime constraints triggered or throughput spiked; reconcile to business approvals and ticketing records. Document control design gaps and remediation plans. Safeguards: audit in read‑only mode; do not create, modify, or deploy agents. Limit data to execution metadata, avoiding transactional content unless needed for ICFR sampling. Align procedures with your AI governance policy and ERP change‑management standards, and coordinate with the ERP owner to prevent disruption.
✎ Try it yourself — Build recipe
Build recipe — Standing audit trace for Oracle Fusion Claw agent runs 1) Trigger and scope - Trigger: Quarterly or monthly ICFR/operational risk oversight cycle. - Scope: One critical workflow (e.g., procure-to-pay) where Fusion Claw executes multi-step work. 2) Access and roles - Request a read-only auditor role with visibility into Fusion Claw governance views and Oracle AI Agent Studio configuration pages. - Confirm no ability to create/modify/deploy agents (documented in access grant). 3) Governance capture - In governance views, locate execution metadata (agent identifier, task name, start/end time, execution outcome, approvals/holds, data domains accessed, performance limits hit). - Use built-in export/download to CSV where available; store in an audit-controlled repository with retention applied. 4) Control mapping - Map each agent task to control objectives (ICFR where relevant) and SoD rules. Document expected approval checkpoints and data scopes for each task. 5) Exception analytics - Analyze the export for: runs without required approvals, tasks executing outside configured data scopes, repeated performance limit hits, and self-approved sequences. - Prepare workpapers citing record IDs, timestamps, and configuration screen captures. 6) Change governance review - In Agent Studio, extract the change history for the in-scope agents (creation, extensions). Verify documented approvals and testing evidence prior to production. 7) Guardrails - Ensure all work is read-only; avoid downloading transactional detail unless required for a sampled test. - Mask any PII if present; restrict repository access to the audit team. 8) Test procedure and go/no-go - Walk through three exceptions with the process owner; confirm root cause and control response. - Go: evidence supports control design and operation; No-go: missing approvals, SoD violations, or uncontrolled scope require remediation with dates/owners.

Source: The Next Web
Summary: OpenAI introduced “dots,” persistent, always‑on AI agents that run on dedicated cloud compute instances. Dots can perform background tasks, maintain state, and chain operations to monitor and act continuously. Initial availability is via enterprise pilots with partner integrations, including Microsoft/Agent 365. OpenAI said participating customers will receive management controls, billing considerations, and pilot details; pricing and general availability were not specified. For internal audit, dots change the control surface: continuous execution, dedicated compute, and lifecycle governance become auditable areas.
How Internal Audit Can Deploy This: If your organization joins an enterprise pilot, insist on an upfront governance frame before any dot is activated. Add dots to the risk register under operational risk and IT risk, noting their persistent runtime and dedicated compute. Establish an inventory with owners, approved purposes, data scopes, and time-bounded authorization. Require that management controls and billing data be enabled and exportable to audit. Use cases: - Continuous monitoring oversight: review management dashboards each week to confirm dots are running within approved task scopes and escalation rules when anomalies occur. - Cost and capacity control: reconcile dot compute hours and billing to approvals and budget to detect runaway tasks or zombie agents. - Access review: compare each dot’s data/resource access to least‑privilege principles; flag any drift. Pilot this quarter: limit to one or two low‑risk automations with clear outcomes. Obtain read‑only access to the dots management controls and billing exports. Run a 30‑day trial with daily usage capture and a weekly access review with system owners. Define a go/no‑go criterion based on exception rate and cost variance. Safeguards: enforce read‑only audit access; require human review of any dot‑initiated changes to production systems; disable external connectors not needed for the pilot; ensure data retention and masking follow AI governance policy; set deactivation criteria and an owner on call for emergency shutdowns.
✎ Try it yourself — Script
# Script — OpenAI dots pilot governance analytics (read-only, auditor-run)
# Purpose: reconcile dots inventory, access scopes, and billing to detect governance exceptions.
# Inputs (CSV files placed in the same directory):
# 1) dots_instances.csv: dot_id, owner, purpose, approved_data_scopes, start_datetime, end_datetime, approval_id
# 2) dots_usage.csv: dot_id, period_start, period_end, compute_hours, cost_amount
# 3) dots_access.csv: dot_id, resource_name, access_level, approved (Y/N)
# 4) owners.csv: owner, manager, department, status (active/inactive)
import csv
from datetime import datetime, timedelta
from collections import defaultdict
# Configurable thresholds for pilot
MAX_DAILY_HOURS = 8 # exceed => investigate
COST_SPIKE_MULTIPLIER = 2.0 # cost > 2x median => investigate
MAX_PILOT_DAYS = 30 # persistent beyond pilot => investigate
# Load helpers
def read_csv(path):
with open(path, newline='', encoding='utf-8') as f:
return list(csv.DictReader(f))
instances = read_csv('dots_instances.csv')
usage = read_csv('dots_usage.csv')
access = read_csv('dots_access.csv')
owners = {r['owner']: r for r in read_csv('owners.csv')}
# Index usage by dot and compute median cost per dot
usage_by_dot = defaultdict(list)
for u in usage:
usage_by_dot[u['dot_id']].append(u)
def median(vals):
s = sorted(vals)
n = len(s)
if n == 0: return 0
mid = n // 2
return (s[mid] if n % 2 == 1 else (s[mid-1] + s[mid]) / 2)
report = []
now = datetime.utcnow()
for inst in instances:
dot_id = inst['dot_id']
owner = inst['owner']
start = datetime.fromisoformat(inst['start_datetime'])
end = datetime.fromisoformat(inst['end_datetime']) if inst['end_datetime'] else None
# 1) Ownership and approval checks
owner_rec = owners.get(owner)
if not owner_rec or owner_rec.get('status','').lower() != 'active':
report.append((dot_id, 'OWNERSHIP', 'Owner missing or inactive', owner))
if not inst.get('approval_id'):
report.append((dot_id, 'GOVERNANCE', 'No documented activation approval_id', ''))
# 2) Pilot duration check
pilot_days = ((end or now) - start).days
if pilot_days > MAX_PILOT_DAYS:
report.append((dot_id, 'DURATION', f'Running {pilot_days} days (> {MAX_PILOT_DAYS})', ''))
# 3) Access scope check (any unapproved resource access or elevated levels)
for a in [r for r in access if r['dot_id'] == dot_id]:
if a.get('approved','N').upper() != 'Y':
report.append((dot_id, 'ACCESS', f'Unapproved access to {a["resource_name"]}', a['access_level']))
if a['access_level'].lower() in ['admin','owner','write_all']:
report.append((dot_id, 'ACCESS', f'Elevated access level: {a["resource_name"]}', a['access_level']))
# 4) Usage and cost anomalies
hours = [float(u['compute_hours']) for u in usage_by_dot.get(dot_id, [])]
costs = [float(u['cost_amount']) for u in usage_by_dot.get(dot_id, [])]
if any(h > MAX_DAILY_HOURS for h in hours):
report.append((dot_id, 'USAGE', f'Compute hours exceed {MAX_DAILY_HOURS} in a period', ''))
med_cost = median(costs)
for u in usage_by_dot.get(dot_id, []):
if med_cost > 0 and float(u['cost_amount']) > COST_SPIKE_MULTIPLIER * med_cost:
report.append((dot_id, 'COST', 'Cost spike vs. median', f"{u['period_start']}–{u['period_end']}"))
# Output: CSV to stdout suitable for workpapers
print('dot_id,category,issue,detail')
for r in report:
print(','.join([str(x).replace(',', ';') for x in r]))
# Workpaper notes:
# - This script is read-only and relies on exports from OpenAI dots management controls and billing.
# - Exceptions flagged should be validated with system owners; retain input and output CSVs as evidence with dates and data provenance.
Disclaimer: This content is provided for general informational purposes only and does not constitute legal, accounting, tax, investment, or other professional advice. Portions were generated using AI tools from public web sources and may contain errors or omissions — verify important details against the primary sources linked above before relying on them. Any example prompts, scripts, templates, or other artifacts are provided “as is” without warranty of any kind, express or implied; test them on non-production data and apply your own professional judgement before use. Cherry Hill Advisory disclaims all liability for any loss or damage arising from the use of, or reliance on, this content or any artifact it contains.
Subscribe now to join the Risk Register community: