Enterprise AI Integration Patterns: Identity, Policy and Evidence

flowchart LR
  A["Alice / approved agent"] --> S["Steward"]
  S --> L["Local MCP tool"] --> W["AD / Windows resource
existing permissions"]
  S --> F["API-backed MCP
(for example Falcon MCP)"] --> C["Cloud / SaaS platform
backend credential scopes"]
  W -. "resource sees Alice" .-> A1["User-bound authority"]
  C -. "Steward still records Alice;
target authorises the API client" .-> A2["Backend authority"]

Why this matters: preserving Alice at a Windows file share and attributing Alice while a Falcon API client performs a Falcon operation are both useful, but they are not the same security property.

• For supported AD/Windows resources, the existing resource ACL remains the authority: the AI path does not need a broad substitute identity.
• For MCP backends that authenticate to their own platform with service/API credentials, Steward adds caller/agent attribution and policy around the call; it does not pretend the target platform received a delegated Alice token when it did not.
• This distinction keeps audits explainable and avoids extending the strongest Steward claim beyond the resources where it actually applies.

Copilot asks. Alice accesses.

flowchart LR
  A["Alice in an approved AI client"] -->|"signed-in identity"| S["Steward
MCP gateway"]
  S -->|"approved MCP tools"| T["Local MCP servers
(logs, files, JDE metadata...)"]
  T -->|"access as Alice"| R["AD-protected files · servers · databases
existing permissions apply"]
  S -. audit: user · agent · tool · outcome .-> L[("Audit")]

When this fits: you have useful local MCP servers and an enterprise AI client that can authenticate to Steward, and the security team’s first question is “what does the protected resource see?”.

• The resource enforces Alice’s permissions. For that resource access, no broad substitute service identity has to be granted Alice’s permissions.
• Existing MCP servers stay local processes; the AI client sees an approved, explicit list of tools.
• Every call is recorded with the user, the client application, the tool and the outcome.

Alice, using an approved agent, reaches the same resources

flowchart LR
  A["Alice in Copilot / Claude / Agent X"] --> G["Identity gateway
(e.g. Aembit MCP Identity Gateway)"]
  G -->|"downstream token:
verified user; agent when configured"| S["Steward"]
  S -->|"verifies issuer · audience · signature"| T["MCP servers"]
  T -->|"access as Alice where supported"| R["AD / Windows resources"]
  G -. "human + agent access policy" .-> Q1["May this caller use this capability?"]
  S -. "resource identity boundary" .-> Q2["Under whose authority does it execute?"]

When this fits: the organisation already governs AI agents centrally — agent identity, conditional access, per-user credential brokering — and wants the last mile onto Windows resources to keep the same discipline.

• The two questions stay separate and complementary: the gateway decides whether Alice may use this agent for this capability; Steward decides whether the operation can happen as Alice where the data lives.
• Steward can validate gateway-issued OpenID/JWT tokens through published signing keys, including rotating JWKS keys; the expected issuer, audience, human claim and agent claim are configured explicitly.
• The agent’s identity travels through: the audit record says which agent Alice used, not merely “the gateway”.

One assistant, four ways to sign in, the same governed tools

flowchart LR
  subgraph SI["Sign in (chosen at the login screen)"]
    J["JD Edwards credentials"]
    P["Single sign-on
(Entra ID, Okta, ADFS, PingOne, Auth0...
via XpreSSO or ESI JDE SSO Suite)"]
    W["Windows credentials"]
    K["Integrated Windows Authentication
(Kerberos, no prompt)"]
  end
  SI --> B["BrainStorm"]
  B -->|"JDE session"| O["JDE Orchestrations
& Compositions"]
  B -->|"Steward token for the signed-in person"| S["Steward"]
  S --> R["MCP servers · supported AD resources
as the user"]
  B -. "standard MCP authorization" .-> G["Identity gateway"] --> S

When this fits: you want an assistant that is not tied to one client vendor, that can work with or without JD Edwards, and that reaches the same Steward-governed tools as everyone else.

• BrainStorm does not need JD Edwards to be useful: a Windows or SSO sign-in gives a governed session over Steward-hosted tools alone; a JDE session is added when the estate has one.
• Supported enterprise SSO providers can feed the same BrainStorm/Steward identity path through XpreSSO or the ESI JDE SSO Suite.
• Where a site runs an identity gateway, BrainStorm connects through it using the standard MCP authorization flow — the user authorises once per session at the gateway.

Three places to say no, or to redact

flowchart LR
  C["AI client"] --> S["Steward"]
  S -->|"tool listing"| P["Policy chain
local rules → AIDR when configured"]
  S -->|"tool input"| P
  P -->|"allow / transformed input"| T["MCP server"]
  T -->|"tool output"| P
  P -->|"allow / redacted output"| S
  S --> C

When this fits: the security team runs an AI detection and response platform and wants tool calls inspected with the real user and agent identity on each event, not a per-collector default.

• Local rules run first and cost nothing: a broad deny for unknown agents, a narrow allow for a service identity, without leaving the network.
• External inspection sees three checkpoints — the tool list a server advertises (poisoned descriptions, conflicting names), the arguments going in, the result coming out — and its verdicts are applied: blocked calls fail cleanly, redactions replace the content before the client sees it.
• Because Steward knows the person, the agent, the backend and the tool per request, each inspection event carries that context — so the inspection service receives per-request caller context rather than relying only on collector-instance metadata.

Governed infrastructure, not a cron job calling a chatbot

flowchart LR
  T["Schedule
(every 10 minutes, since last success)"] --> B["BrainStorm
as a dedicated service identity"]
  B -->|"read-only tools only"| S["Steward"]
  S --> F["Falcon MCP
(read-only)"]
  S --> G["Logs MCP
evidence profile"]
  B --> R["Structured report:
severity · confidence · finding
affected assets · evidence · action"]
  R -->|"severity ≥ threshold"| N["Notification
(webhook / SOC channel)"]

When this fits: you want continuous, local-LLM triage of security-relevant activity across production servers, with the same identity, policy and audit controls a human’s session has.

• The watch is an ordinary Steward client with a dedicated identity: it can be allow-listed, policy-restricted to read-only tools, and every call it makes is in the audit.
• With a local model, raw log evidence and the model interaction can remain inside the customer environment. If the watch also queries Falcon, those Falcon API/MCP calls still go to Falcon; local log content is not sent there unless a workflow deliberately includes it.
• The report has a fixed shape, so a threshold can trigger a notification and a workflow can parse it.

A detection becomes a finding, inside the tools the SOC already uses

flowchart LR
  D["Falcon detection"] --> W["Falcon Fusion SOAR workflow"]
  W -->|"POST /security/investigate
(detection as context)"| A["Steward security API"]
  A --> B["BrainStorm security watch
(on demand)"]
  B --> S["Steward"] --> M["Falcon MCP · Logs MCP"]
  B --> R["Structured finding"]
  W -->|"poll status · read severity + report"| A
  W --> C["Falcon case / ticket"]

When this fits: the SOC works in Falcon and wants an investigation started automatically from a detection, using the organisation’s own logs, without a new console.

• Fusion talks to Steward the way it talks to anything else: an HTTP action or an imported OpenAPI definition, an API key, a job id to poll.
• The investigation runs as the governed watch identity through the same gateway, so “what did the AI look at” is answered by the same audit as everything else.
• The finding follows a fixed structure: severity, confidence, affected assets, evidence references and a recommended action. Fusion can act on the status/severity fields without treating arbitrary model prose as the control signal.

Response boundary: the security watch is deliberately read-only. If a Falcon/Fusion workflow later contains containment, case-management or other response steps, those remain Falcon actions under Falcon permissions and approval rules; the investigation loop does not silently turn a model conclusion into a destructive action.

A finding cites records, not pasted text

flowchart LR
  I["Investigation"] -->|"SearchEvidence"| E["Evidence record
server · path · file identity
line · offset · time · hash · search id"]
  E --> F["Finding cites
search id + evidence hash"]
  F -->|"days later"| V["Re-verify
(Logs tool or Steward security API)"]
  V -->|"file identity + line still match?"| O{"verified · file changed · line changed"}

When this fits: findings will be acted on, audited or disputed, and “the AI said so” is not an acceptable basis.

• Each cited line carries the file’s identity at observation time and a hash binding the text to that exact place. If the log rotated or was edited since, re-verification says so instead of quietly returning a different line.
• An assistant can paraphrase; it cannot produce a hash that verifies against a line that never existed. Reviewers check hashes, not recollection.
• Every record carries its search id, which can be correlated with Steward’s request audit to identify the caller and agent that ran the search, so provenance is a lookup. The file identity is deliberately lightweight — size, time and a hash of the file head — so read this as reproducible evidence references with integrity checks, not a forensic image.

One log estate, separate tool profiles and callers

flowchart LR
  U["JDE / operations user"] --> B["BrainStorm"] --> S["Steward"]
  W["SecurityWatch
dedicated identity"] --> S
  S --> L1["Logs MCP
operations profile"]
  S --> L2["Logs MCP
security evidence profile"]
  L1 --> E["Configured Windows / Linux estate
including JD Edwards logs"]
  L2 --> E
  B --> J["JDE MCPs · Orchestrations
Compositions · metadata"]
  L1 -. "interactive troubleshooting" .-> O["Operations"]
  L2 -. "SearchEvidence / GetEvidence" .-> X["Security investigation"]

When this fits: the same servers matter to application support and to security, especially in JD Edwards estates where an incident may cross Enterprise Server, AIS, WebLogic, batch, integration and operating-system logs.

• The Logs server does not need a separate ingestion pipeline for the security use: different profiles expose different tool families over the same configured estate.
• Interactive troubleshooting and unattended security investigation can use different Steward backends, allowed agents and identities even when they ultimately read the same underlying files.
• The cybersecurity capability can be deployed with the JD Edwards stack, beside it, or without JD Edwards at all; the identity, MCP and evidence layers are the same.

Move the model without moving the permissions model

flowchart LR
  subgraph M["Model choice"]
    H["Hosted model
ChatGPT / Claude / other"]
    L["Local model
on-prem / private runtime"]
  end
  H --> B["BrainStorm / approved AI client"]
  L --> B
  B --> S["Steward"] --> T["Approved MCP tools"] --> R["Enterprise resources"]
  L -. "raw log evidence can remain local" .-> R
  H -. "only returned tool content enters
the hosted-model conversation" .-> B

When this fits: some investigations can use a hosted model while others involve logs or operational data that must stay inside the customer’s environment.

• The model location is independent of the resource authorization model: moving from a hosted model to a local one does not require a second set of file, server or database permissions.
• With a local model and local MCP backends, raw logs can remain on premises. Calling an external backend such as Falcon is still an explicit external interaction; “local model” is not used as a blanket claim that every configured integration is offline.
• A hosted model receives only the content returned through the approved MCP operation; it is not given a broad filesystem or server identity.

flowchart TB
  subgraph Clients
    C1["Copilot / Claude / Agent X"]
    C2["BrainStorm
(JDE · SSO · Windows · IWA sign-in)"]
    C3["Scheduled / on-demand watch"]
    C4["Falcon Fusion SOAR"]
  end
  C1 --> AG["Aembit / identity gateway
(optional)"] --> S
  C1 --> S["Steward"]
  C2 --> S
  C2 --> AG
  C4 -->|"HTTP / OpenAPI"| API["Steward security API"] --> C3
  C3 --> S
  S --> PO["Policy chain
local rules → AIDR when configured"]
  PO --> M["MCP servers
Logs · Falcon · JDE metadata · other STDIO tools"]
  M --> W["AD / Windows resources
as the user where supported"]
  M --> F["Falcon / SaaS APIs
under backend credential scopes"]
  S --> AU[("Audit: user · agent · backend · tool · outcome")]
  M --> EV[("Evidence records / search ids")]

Read it from the outside in. Clients differ; the Steward boundary is shared; an identity gateway and AIDR are optional layers around it; local AD resources can keep the user as the authority, while API-backed MCPs retain their own target-platform credential model. The common pieces are caller/agent attribution, policy, audit and evidence.