Integration Surface
Connected Systems
The detection, ticketing, approval, identity, and observability systems this agent is designed to plug into — and the tight boundary it keeps around each one.
A bank already runs a mature operational stack. It has a detection platform, a ticketing system, an approval channel, identity providers, change and observability tooling, and a GRC system of record. The remediation agent is designed to plug into those systems rather than replace any of them.
No new systems of record. The agent is a layer, not a replacement.
Every integration below is either simulated in this prototype or scoped for a near-term phase. Each one is described with its direction of data flow, its operational purpose, and the narrow permission the agent would hold against it in production.
Group 01
Detection & risk signal
Upstream platforms that surface the control gap the agent acts on.
Risk detection platform
SimulatedBrontë
Receives gap exports in structured JSON with control ID, evidence, and severity.
SIEM
SimulatedSplunk Enterprise Security
Consumes correlated alerts and detection rules linked to operational controls.
SecOps telemetry
Coming soonChronicle
Ingests long-retention security telemetry to confirm gap reproducibility over time.
GRC risk register
SimulatedServiceNow GRC Risk
Pulls the canonical control definition, owner, and residual risk rating.
Group 02
Ticketing & work management
Where remediation becomes real, tracked, accountable work inside the bank.
Ticketing
SimulatedJira Cloud
Opens drafted remediation tickets in a scoped project with labels and approver.
Change & incident
SimulatedServiceNow ITSM
Links remediation to the canonical change record and pulls incident status back.
Engineering tracker
SimulatedLinear
Alternative path for engineering-heavy remediations routed to platform teams.
Operational work
Coming soonAsana
Used by operational-risk teams to track non-engineering remediation actions.
Group 03
Approval & comms
Where a named human approver sees, reviews, and explicitly signs off.
Approval channel
SimulatedSlack
Posts a structured approval card to a designated channel and waits for sign-off.
Approval channel
SimulatedMicrosoft Teams
Equivalent approval surface for banks standardised on Microsoft 365.
Notification
SimulatedEmail (Outlook / Gmail)
Fallback approval and notification surface for control owners outside chat tools.
Escalation
Coming soonPagerDuty
Escalates stalled approvals on critical-severity gaps to an on-call risk owner.
Group 04
Identity & change
The systems of record for who can do what, and where change actually lands.
Identity provider
SimulatedOkta
Resolves control owners and issues scoped, short-lived tokens for every tool call.
Identity provider
SimulatedAzure AD / Entra ID
Equivalent identity surface for Microsoft-first institutions and their change paths.
Cloud access control
SimulatedAWS IAM
Reads policy state on detected access-control gaps; writes remain strictly proposal-only.
Source & change
SimulatedGitHub / GitLab
Opens a pull request with the generated change spec; the agent never merges directly.
Group 05
Observability & evidence
Where the agent draws telemetry, proves the fix worked, and files the evidence pack.
Observability
SimulatedDatadog
Reads metrics, logs, and traces to validate the remediation behaved as intended.
Log platform
SimulatedSplunk
Queries audit log events that prove the control is now operating correctly.
Audit log
SimulatedAWS CloudTrail
Sources account-level API evidence for access-control and configuration gaps.
GRC evidence store
SimulatedArcher / MetricStream
Appends regulator-ready evidence to the control record, scoped to that control only.
Authorisation & safety model
Scoped, short-lived, least-privilege.
The integration model is built around a simple assumption: the agent should be able to do exactly the thing it was asked to do on the specific control it was asked to do it on, and nothing else. That shape is consistent with the expectations placed on regulated workflows under APRA CPS 234 and CPS 230.
Dedicated service account per integration
Every outbound system has its own identity. No shared credentials, no admin keys, no human-user impersonation.
Scoped to specific projects and channels only
Jira access is restricted to the remediation project; Slack to a single approval channel; GRC to one control record.
Short-lived access tokens (1 hour maximum)
Every tool call uses a freshly minted, time-bound token. Long-lived secrets are never handled by the agent runtime.
Human-approved kill switch on every destructive tool
A named control owner can revoke the agent's access to any downstream system from a single control panel, instantly.
Data Flow
From detection to evidence, end-to-end.
A single remediation traces a bounded path through the bank's existing stack. The agent is the connective tissue; every box on either side of it remains the system of record for its own domain.
Step 01
Detection platform
Brontë, Splunk ES, or GRC surfaces a verified control gap.
Step 02
Risk engineering agent
Diagnoses, plans, drafts — produces artefacts, not actions.
Step 03
Approval channel
Named control owner approves or rejects in Slack or Teams.
Step 04
Change system
Approved remediation is filed to Jira, ServiceNow, or GitHub.
Step 05
GRC evidence store
Evidence pack is appended to the control in Archer or MetricStream.
Outbound Write Surface
Every write action the agent can take.
The write surface is deliberately narrow. Anything outside this list is either read-only or proposal-only, and any destructive call requires explicit human approval first.
- 01
Create Jira ticket in the designated remediation project only.
- 02
Post approval message to the designated Slack or Teams channel.
- 03
Append evidence to the GRC pack, scoped to the affected control.
- 04
Open a pull request with the generated change spec — never merge.
- 05
Submit the validation test to the sandbox environment only.
Prototype vs Production
What this prototype simulates, and what production would do.
A side-by-side view so the shape of the production system is clear from the demo. The behaviours below remain illustrative — real deployment would require institution-specific policy, security review, and change governance.
Prototype
Creates a synthetic Jira draft in the browser.
Production
Calls the Jira Cloud REST API using an OAuth2 service account.
Prototype
Streams agent events to the local browser only.
Production
Publishes events to an internal Kafka topic for audit replay.
Prototype
Shows the approval card inline in the UI.
Production
Posts a signed approval card to a dedicated Slack or Teams channel.
Prototype
Evidence pack renders as a downloadable document.
Production
Evidence is lodged directly against the control in Archer or MetricStream.
Prototype
Validation tests run as illustrative text.
Production
Validation executes in a sandboxed CI runner with human-reviewed results.
Prototype
Control owner identity is hard-coded in the gap fixture.
Production
Owner is resolved live from Okta or Entra ID against the control record.