Integrations - Guardway

What this is for

Settings → Integrations is the catalog of third-party connections for your organization. Each integration is a card on a searchable hub; clicking View integration opens a two-step dialog — Overview (what the connector does) and Connect (credentials and Test & Connect). Available today:

GitHub — AI-dependency discovery for Discovery and optional pull request scanning, via the Guardway GitHub App.
Azure DevOps — the same repository discovery and scanning for Azure Repos, through a service principal in your own tenant (rolling out; see Azure DevOps).
Azure AI Foundry and Amazon Bedrock — cloud agent inventory for Agents and Topology.
Microsoft Entra ID — identity hydration and expanded ASI03 findings on agents (no separate agent list).
SIEM Export — stream your gateways’ (and endpoints’) logs to your own SIEM: Splunk HEC, syslog CEF/LEEF, an NDJSON webhook, Microsoft Sentinel, Datadog, Google SecOps (Chronicle), or AWS Security Lake — in Guardway’s native shape or as OCSF. See SIEM Export.
Anthropic Compliance — ingest your Claude Enterprise Activity Feed and compliance signal alongside your gateway audit logs. See Anthropic Compliance.
Slack — route alert rules and operational signals to Slack channels. See Slack.

Integrations are platform-scoped — configure once per organization, not per gateway.

The integrations hub

Search and filters

Element	Notes
Search integrations…	Filters cards by name, tagline, category, or slug.
All	Shows every integration (default).
Source control	GitHub, Azure DevOps (rolling out), GitLab (soon).
Identity & access	Microsoft Entra ID, Okta (soon).
Collaboration & work	Slack, Jira (soon).
Cloud AI platforms	Azure AI Foundry, Amazon Bedrock.
Security & SIEM	SIEM Export, Anthropic Compliance.

Card states

Badge	Meaning
Connected	Integration is active (GitHub App installed, Azure DevOps organization connected, Foundry SP, Bedrock IAM role, or Entra Active).
Connect	Available but not yet configured (e.g. Amazon Bedrock).
Soon	On the roadmap (Okta, Jira, GitLab).

Each card shows the integration name, one-line tagline, and View integration.

Integrations catalog with category filters — Settings → Integrations hub

Integration dialog

Every View integration opens the same dialog shell (except GitHub, which has its own screen):

Element	Notes
Step pills	OVERVIEW then CONNECT. Use Next and Cancel in the footer.
Overview	Tagline, feature checklist, capability cards, Works with badges, Category chip, Free label.
Connect	Integration-specific fields and Test & Connect (or Test Microsoft Graph access for Entra). Connected integrations show Resync and Disconnect where applicable.

Deep links: opening ?open=<slug> on the integrations route selects the card automatically (azure-devops, azure-foundry, aws-bedrock, entra-id). ?open=github forwards to the GitHub screen.

Azure AI Foundry integration dialog on Overview step — Integration dialog — Overview step (Azure AI Foundry)

GitHub

GitHub connects through the Guardway GitHub App, not a personal access token. You install the App on a GitHub organization (or user account), choose which repositories it can read, and Guardway discovers and scans those repositories for Discovery. Optionally, the same App scans pull requests and reports findings on the PR itself. Unlike the other integrations, GitHub has its own screen instead of a dialog: Settings → Integrations → GitHub opens /settings/integrations/github (?open=github on the hub forwards there).

What the App can access

Permission	Access	Used for
Repository contents	Read	Scanning code for AI SDKs, models, MCP tools, gateway configs, and secrets.
Metadata	Read	Listing organizations and repositories.
Pull requests	Write	PR scanning only — reading the changed files and posting the summary and inline comments.
Checks	Write	PR scanning only — the Guardway check run.

Access covers only the repositories you select at install time (All repositories or Only select repositories). You can change the selection later in GitHub under the App’s installation settings; repositories you remove stop being scanned.

If the App was installed before PR scanning existed, GitHub asks an organization owner to approve the new Pull requests and Checks permissions. Until then, Guardway shows a notice under the account with a Review on GitHub link (github.com/settings/installations). Discovery keeps working without them.

The GitHub screen

Tab	Shown	Contents
Organizations	Always	Not connected: Install the GitHub App. Connected: the organizations the App can read, with sync and scan controls (see Organizations).
Connection	Connected only	GitHub accounts (every installation, with its Scan pull requests toggle) and connection facts — Installed on, Connected on, Access (Read-only).
What you get	Always	Features, capabilities, and Works with surfaces.

The header shows Connected, Not connected, or Status unknown (the console couldn’t reach the integrations API — this does not mean you need to reconnect; click Retry).

How to connect (GitHub)

Open the GitHub screen

Settings → Integrations → GitHub.

Install the App

Click Install GitHub App. On GitHub, pick the organization or account and the repositories Guardway can read.

Authorize Guardway

GitHub asks you to authorize Guardway. This confirms you control the installation and binds it to your Guardway organization.

Confirm the connection

GitHub returns you to Guardway. The header shows Connected and the Organizations tab lists what the App can read.

Verify in Discovery

Open Discovery → Repositories.

Multiple GitHub accounts

One Guardway organization can connect several GitHub organizations or user accounts. On Connection → GitHub accounts, click Add another GitHub account and repeat the install for the next account. Repositories from every connected account are discovered and scanned together. Each account row shows its name, GitHub installation ID, and status. An account whose App was uninstalled or suspended on GitHub shows a warning badge (for example disconnected) — reinstall the App on GitHub to reconnect it, or Remove it here. Remove unlinks that one installation: Guardway stops scanning its repositories, and their scan history is kept. To fully revoke access, also uninstall the Guardway App on GitHub.

Pull request scanning

Every connected account has a Scan pull requests toggle (off by default). Only owners and admins can change it; other roles see its current state. When it’s on, Guardway scans a pull request when it’s opened, reopened, marked ready for review, or gets a new push, and posts:

Output	What it contains
Guardway check	A check run on the head commit: Scanning while it runs, then a severity count table (e.g. 3 finding(s) in changed files).
Summary comment	One comment per PR, updated on every push: findings in the files the PR changes, by severity, type, and location, plus a prompt to fix them with an AI coding agent.
Inline comments	Review comments on the exact changed line for code (static) and secret findings — up to 25 per push, worst first. A finding already commented on by an earlier push is not repeated.

How it behaves:

Never blocks merges. The check always completes as neutral or success — it never fails, so it can’t gate a branch-protection rule.
Results stay on the PR. PR scan findings are not added to the dashboard or to Discovery.
Changed files only. Guardway scans the PR’s latest commit but reports only findings in files the PR changes.
Secrets are masked. A secret finding shows only its rule, location, and a redacted snippet — never the credential.
Skipped: draft PRs (until marked ready for review), PRs from forks, closed PRs, and accounts that aren’t active.
New push supersedes. When a newer commit arrives, the older check is marked Superseded.
At capacity, the check shows Skipped: scanning capacity is full — push again later to retry.

Turn on PR scanning per account, so you can pilot it on one GitHub organization before enabling it everywhere.

Fix with an AI coding agent

When the summary comment lists a secret, code (static), or dependency finding, it ends with a collapsed Fix with an AI coding agent section. Expand it and copy the prompt into your AI coding agent (Claude Code, Cursor, Copilot, or similar), run from a checkout of the pull request’s branch. The agent then fixes each listed finding, worst first, and reports what it changed. The Guardway check points to the prompt when there is one. What the prompt asks for:

Finding	What the agent is asked to do
Secret	Remove the hard-coded credential from the code, tests, and fixtures, and read it at runtime from an environment variable or your existing secret store.
Code (static)	Fix the weakness at that line, guided by the rule’s own description of what safe code looks like.
Dependency	Upgrade the package to the fixed version and regenerate the lockfile. When no fixed version exists, replace or remove the package, or report that it couldn’t.

Things to know:

Only findings with a code fix. Compliance and skill findings stay in the summary table only. The prompt lists up to 25 findings; fix those, push, and the next scan’s prompt covers the rest.
Safe to paste. The prompt is written by Guardway, not copied from your code. It never quotes the code, comments, or finding descriptions from the pull request, so a pull request can’t plant instructions for your agent through it. It also tells the agent to treat the repository’s content as data and not to run commands the repository suggests.
Secrets are never included. A secret is named only by its rule and location. Rotate the credential yourself: removing it from the code doesn’t remove it from the git history.
Review before you push. The agent’s changes are a starting point. Push them like any other commit, and Guardway scans again.

Disconnect

With a single account, Disconnect GitHub in the screen header stops discovery scans for it. With multiple accounts, use Remove on each row instead.

Disconnecting or removing in Guardway does not uninstall the App. The App stays installed on GitHub until you uninstall it there (GitHub → Settings → Applications → Installed GitHub Apps). If you uninstall or suspend it on GitHub first, Guardway notices automatically and marks the account disconnected.

Azure DevOps

Azure DevOps is rolling out per organization. If you don’t see the Azure DevOps card under Source control, ask your Guardway contact to enable it.

Azure DevOps connects an organization (dev.azure.com/<organization>) through a service principal you create in your own Microsoft Entra tenant. There is no Guardway app to install and no consent prompt: you register an app, add it to the organization as a user, and paste its credentials. Guardway then lists the organization’s projects and Git repositories and scans them for Discovery the same way it scans GitHub repositories.

Fields

Field	Required	Notes
Name	No	Defaults to the organization name.
Organization	Yes	The organization name (`contoso`) or its URL (`https://dev.azure.com/contoso`, `https://contoso.visualstudio.com`).
Tenant ID	Yes	The Entra tenant your Azure DevOps organization is connected to (Organization settings → Microsoft Entra).
Client (App) ID	Yes	The app registration’s Application (client) ID.
Client Secret	Yes	A client secret of that app. Stored encrypted; never shown again.

How to connect (Azure DevOps)

In Microsoft Entra → App registrations → New registration, in the tenant your Azure DevOps organization is connected to. Under Certificates & secrets, create a client secret and copy its value. No API permissions are needed.

Add the app to your Azure DevOps organization

In Azure DevOps → Organization settings → Users → Add users, search for the app by name and add it with Basic access. Then give it Reader on each project Guardway should scan (project Settings → Permissions → Readers).

Connect in Guardway

Settings → Integrations → Azure DevOps → Connect. Enter the organization, tenant ID, client ID and secret, then Test & Connect. Guardway checks that the app can read the organization before it saves anything, then runs the first sync.

Verify in Discovery

Open Discovery → Repositories: the organization’s repositories appear as project/repository, ready to scan.

What Guardway does with it

Read-only by default. Guardway lists projects and repositories and downloads the code of a repository when you scan it. It writes to Azure DevOps only when you turn something on: the service hook subscriptions of Keep inventory in sync, and the status and comments of Pull request scanning.
Sync. Sync (on the connection, or Sync on Organizations) lists every project the app can read. A repository that disappears is retired only after a complete listing; if one project can’t be read, nothing is removed and the connection shows the error.
Visibility is the project’s (private or public).
Scoring. Azure DevOps repositories are scored from their code. GitHub-only signals (stars, contributors, branch protection) are not available, so a repository’s score can differ from a comparable GitHub one.

Scheduled scans

Under Scheduled scans in the Azure DevOps dialog, click an organization to rescan its repositories automatically: once a day, a week or a month, at an hour in a time zone you pick, for all of its repositories (including ones added later) or a chosen few. It works the same way as on GitHub: saving never starts a scan right away, the first one runs at the next scheduled time, and a repository already scanned since then is skipped. Only owners and admins can change a schedule.

Keep inventory in sync

Without it, repositories created, renamed, disabled or deleted in Azure DevOps show up at the next Sync. Turn on Keep inventory in sync for an organization and Guardway subscribes each of its projects to Azure DevOps service hooks for repository created, deleted, renamed and status changed, so the inventory follows within seconds. Every sync subscribes projects created since, and removes the subscriptions of projects that are gone.

Permission. The app needs the View subscriptions and Edit subscriptions service hook permissions in the organization. Members of Project Administrators have them; otherwise grant them in Organization settings → Permissions. If it can’t create any subscription, the switch stays off and says why.
Trust. Each delivery carries a secret header unique to the connection, and Guardway re-reads the repository from Azure DevOps before changing anything, so a delivery only tells Guardway which repository to refresh.
Turning it off (or removing the connection) deletes the subscriptions. You can see them in Azure DevOps under Project settings → Service hooks.

Pull request scanning

Turn on Pull request scanning for an organization and Guardway scans the latest commit of every active pull request when it’s opened or pushed to. Results go only on the pull request:

a Guardway status (Succeeded when nothing is found in the files the pull request changes, Not applicable otherwise). It never reports Failed, so a branch policy that requires it never blocks a merge;
one summary comment listing the findings in the changed files, updated in place on every push, with the same Fix with an AI coding agent prompt as on GitHub;
inline comments on the changed lines for secrets and code findings (at most 25 per push, never repeated on a later push).

Draft pull requests and pull requests from forks are skipped. Turning it on also turns on Keep inventory in sync, because pull request events arrive through the same service hooks; turn pull request scanning off before you turn lifecycle sync off.

Permission. On top of Reader, the app needs Contribute to pull requests on the repositories (to post the status and comments), and the service hook permissions above. Without it the scan still runs, but nothing is posted.
Scoring. As for repository scans, Azure DevOps findings come from the code only.

Several organizations

Each Azure DevOps organization is its own connection. Click Add organization to connect another; an organization can be connected once per Guardway organization.

Rotate the secret

Client secrets expire. On the connection, choose Update service principal and enter the new tenant, client and secret values (the organization can’t change). Guardway verifies the new secret before replacing the old one, so a mistyped secret never breaks a working connection.

Troubleshooting

Message	Fix
Tenant not found	Check the tenant ID.
App registration not found in this tenant	The client ID and tenant ID don’t belong together.
The client secret is invalid or expired	Create a new secret and update the connection.
Azure DevOps rejected the service principal	Add the app as a user of the organization, and check the organization is connected to that tenant.
The service principal lacks access	Give it Basic access and Reader on the projects to scan.
The service principal sees no projects yet	The connection works but can’t read any project: add it to the projects’ Readers, then Sync.
Nothing appears on a pull request	With Pull request scanning on, give the app Contribute to pull requests on the repository. Drafts and forks are skipped.
The service principal cannot manage service hooks	Only for Keep inventory in sync: grant the app View subscriptions and Edit subscriptions (or add it to Project Administrators), then turn it on again.

Remove

Remove stops scanning the organization and deletes its service hook subscriptions. Its repositories leave the inventory and their past scans are kept. To fully revoke access, also remove the app from the Azure DevOps organization (or delete its secret in Entra).

Azure AI Foundry

Field	Required	Notes
Tenant ID	Yes	Entra tenant GUID.
Subscription ID	Yes	Subscription with AI Foundry resources.
Client (App) ID	Yes	Service Principal application id.
Client Secret	Yes	Secret Value (not Secret ID). Encrypted at rest.

Read-only Service Principal — lists agents, tools, MCP servers, and models.

Connection state

Element	Notes
Status badge	`Connected` or `Disconnected`.
Metadata	Subscription label and connection date.
Test & Connect	Authenticates before save.
Resync	Immediate discovery refresh for Agents.
Disconnect	Removes credentials and discovered inventory for that subscription.

Limits

One Azure subscription per organization in v1.
Data-plane role required at AI Services account scope (see permissions below).

How to configure (Azure AI Foundry)

Azure AI Foundry — Connect step

App registrations → New registration (single tenant, no redirect URI). Copy Application (client) ID.

Create a client secret

Certificates & secrets → copy the secret Value immediately.

Grant subscription Reader

Subscriptions → IAM → Reader (or Azure AI Developer) for the SP.

Grant account-scoped data-plane access

On each AI Services account → IAM → Azure AI User or Azure AI Developer for the SP. Subscription-level alone returns 401 on agent APIs.

Connect in Guardway

View integration → Connect → paste four fields → Test & Connect.

Verify agents

Open Agents or Dashboard → Agents. Use Resync after adding projects.

Required Azure permissions

Capability	Plane	Role	Scope
List subscription / resource groups	Management	Reader	Subscription
List AI Services accounts	Management	Reader or Azure AI Developer	Subscription
Read agents, tools, MCP	Data	Azure AI User or Azure AI Developer	AI Services account

Microsoft Entra ID

Field	Required	Notes
(none)	—	Reuses the Service Principal from Azure AI Foundry. Grant Microsoft Graph application permissions on the same app registration.

Connection state

Element	Notes
Status badge	`Active`, `Pending consent`, `Disconnected`, or `Error`.
Service Principal banner	Shown when Foundry is not connected; Connect Azure AI Foundry button.
Test Microsoft Graph access	Reports Granted vs Still need admin consent; flips to Active when required scopes are present.
Last identity sync	Shown when Active and at least one sync completed.

Required Microsoft Graph permissions

Scope	Required	Unlocks
`Application.Read.All`	Yes	Credential lifecycle rules.
`Directory.Read.All`	Yes	Principals, owners, grants, directory roles.
`AuditLog.Read.All`	No	`asi03.dormant_principal` (needs AAD Premium P1/P2).

Limits

One tenant (same as Foundry SP).
Identity sync chains after Foundry Resync — no separate Entra Resync button yet.

How to configure (Microsoft Entra ID)

Microsoft Entra ID — Connect step

Connect Azure AI Foundry first

Entra reuses that Service Principal.

Grant Graph admin consent

App registrations → your SP → API permissions → add the three Graph application permissions → Grant admin consent.

Test Microsoft Graph access

On the Entra Connect step, click Test Microsoft Graph access until both required scopes show Granted and status is Active.

Resync Foundry

Azure AI Foundry → Resync chains identity sync. Open an agent detail page to see Identities.

Amazon Bedrock

Guardway connects to Bedrock by assuming a read-only IAM role in your AWS account. You never give Guardway an AWS access key, and Guardway stores no AWS secret: only the role ARN and region.

Field	Required	Notes
Role ARN	Yes	The role Guardway assumes, e.g. `arn:aws:iam::123456789012:role/GuardwayBedrockDiscovery`.
Region	Yes	Bedrock region (e.g. `us-east-1`). Each account + region is its own connection; one role serves every region of an account.

Read-only. It inventories both kinds of Bedrock agent:

Bedrock Agents (Classic): agents, their action groups, knowledge bases, model and guardrail.
Amazon Bedrock AgentCore: AWS’s replacement for Agents Classic, which is closed to new AWS accounts. Guardway lists:
- Harnesses (agents defined by a model, system prompt and tools), with their model, instructions, tools, MCP servers, AgentCore Gateway tools, memory, guardrail and execution role.
- Runtimes (agents you deploy as code), with their protocol, network mode and execution role. A runtime’s model and tools live in its code, so Guardway can’t list them. The runtime a harness runs on is shown as part of that harness, not as a separate agent.

Each agent’s Type in Agents says which kind it is: Agents Classic, AgentCore harness or AgentCore runtime. Guardway never reads environment variables, MCP server headers or credential providers.

How the role is trusted

The role’s trust policy allows sts:AssumeRole from Guardway’s AWS account (563763293556) only when:

the call carries your organization’s External ID (shown on the Connect step, starts with gw-). It is unique to your organization and generated by Guardway, which stops another Guardway customer from pointing Guardway at your role (the “confused deputy” problem).
the caller is one of Guardway’s two discovery services (guardway-cad-api-lambda-role, guardway-cad-worker-lambda-role).

Each scan uses a 15-minute session named guardway-cad-<connection id>, which shows up in your CloudTrail.

Required AWS IAM permissions

The role’s permissions policy grants exactly what discovery calls:

Capability	Action(s)
List/read agents and action groups	`bedrock:ListAgents`, `bedrock:GetAgent`, `bedrock:ListAgentActionGroups`, `bedrock:GetAgentActionGroup`
Knowledge bases	`bedrock:ListAgentKnowledgeBases`, `bedrock:ListKnowledgeBases`
Guardrails	`bedrock:ListGuardrails`
AgentCore harnesses	`bedrock-agentcore:ListHarnesses`, `bedrock-agentcore:GetHarness`
AgentCore runtimes	`bedrock-agentcore:ListAgentRuntimes`, `bedrock-agentcore:GetAgentRuntime`
AgentCore gateways and their tools	`bedrock-agentcore:ListGateways`, `bedrock-agentcore:GetGateway`, `bedrock-agentcore:ListGatewayTargets`, `bedrock-agentcore:GetGatewayTarget`

The AgentCore actions are listed one by one on purpose. Don’t replace them with bedrock-agentcore:Get*: that wildcard also allows calls that return API keys and OAuth tokens. A role that can read only one kind still connects, with a warning. It inventories that kind and keeps the other kind’s agents from earlier syncs.

How to configure (Amazon Bedrock)

Amazon Bedrock — Connect step

Open the Connect step

Settings → Integrations → Amazon Bedrock → Connect. Note your External ID.

Create the role with CloudFormation

Type the region, then click Launch stack in AWS. Signed in to the AWS account you want to scan, acknowledge that the stack creates an IAM role and click Create stack. The External ID is already filled in.

Copy the role ARN

When the stack shows CREATE_COMPLETE, open its Outputs tab and copy RoleArn.

Connect in Guardway

Paste the Role ARN, check the Region, then click Test & Connect. Guardway assumes the role, confirms the account, and checks that it can list Bedrock Agents and AgentCore agents before saving.

Verify agents

Open Agents. Use Sync after adding agents in AWS.

Without CloudFormation (console or Terraform)

Expand Set up manually (console or Terraform) on the Connect step to copy the trust and permissions policies with your External ID filled in. With Terraform:

resource "aws_iam_role" "guardway_bedrock" {
  name = "GuardwayBedrockDiscovery"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { AWS = "arn:aws:iam::563763293556:root" }
      Action    = "sts:AssumeRole"
      Condition = {
        StringEquals = { "sts:ExternalId" = "gw-..." } # your External ID
        ArnEquals = {
          "aws:PrincipalArn" = [
            "arn:aws:iam::563763293556:role/guardway-cad-api-lambda-role",
            "arn:aws:iam::563763293556:role/guardway-cad-worker-lambda-role",
          ]
        }
      }
    }]
  })
}

resource "aws_iam_role_policy" "guardway_bedrock" {
  name = "GuardwayBedrockDiscovery"
  role = aws_iam_role.guardway_bedrock.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "GuardwayBedrockDiscovery"
        Effect = "Allow"
        Action = [
          "bedrock:ListAgents", "bedrock:GetAgent",
          "bedrock:ListAgentActionGroups", "bedrock:GetAgentActionGroup",
          "bedrock:ListAgentKnowledgeBases", "bedrock:ListKnowledgeBases",
          "bedrock:ListGuardrails",
        ]
        Resource = "*"
      },
      {
        Sid    = "GuardwayAgentCoreDiscovery"
        Effect = "Allow"
        Action = [
          "bedrock-agentcore:ListHarnesses", "bedrock-agentcore:GetHarness",
          "bedrock-agentcore:ListAgentRuntimes", "bedrock-agentcore:GetAgentRuntime",
          "bedrock-agentcore:ListGateways", "bedrock-agentcore:GetGateway",
          "bedrock-agentcore:ListGatewayTargets", "bedrock-agentcore:GetGatewayTarget",
        ]
        Resource = "*"
      },
    ]
  })
}

Connection state

Element	Notes
Status badge	`Active`, `Error`, `Paused`, Update available (the role is older than the current template, see below), or Needs migration (see below).
Metadata	Account and region (e.g. `Account 123456789012 · us-east-1`) and last sync.
Test & Connect	Assumes the role and probes Bedrock before saving.
Sync	Immediate refresh for Agents.
Update IAM role	Point the connection at another role in the same account.
Remove connection	Removes the connection and the Bedrock inventory for that account and region. Delete the role (or the CloudFormation stack) in AWS too.

Updating an existing role (Update available)

Guardway’s role template is versioned. Version 2 added AgentCore. A role made from an older template keeps working, but it can’t read the newer agent kinds, and the stack doesn’t update itself. Guardway checks what the role can do on every test and sync. When the role is older than the current template, the connection shows Update available and lists the agent kinds it can’t inventory. The Agents inventory shows a notice with an Update role link. The Guardway Assistant’s setup status also recommends the update. Your existing agents keep syncing in the meantime. To update, click Update role on the connection:

Open CloudFormation, which opens the guardway-bedrock-discovery stack list in the connection’s region, in the AWS account of that connection.
Select the stack, then click Update → Replace existing template and paste the template URL shown in Guardway (it is the same URL Launch stack in AWS uses).
Keep the parameters, acknowledge that the stack changes an IAM role, and submit.
When the stack shows UPDATE_COMPLETE, click Check again. Guardway syncs, and the badge clears once the role can read everything.

The role keeps its ARN, so nothing changes in Guardway. Roles not made with CloudFormation (console or Terraform): replace the role’s Guardway permissions policy with the one under Role not created with CloudFormation? (the same policy as above), then click Check again. To see which template version a stack runs, open its Outputs tab (TemplateVersion), or look at the role’s guardway:template-version tag. Stacks created before template versioning have neither, and are version 1.

Migrating from access keys

Connections created with an IAM access key stopped syncing when IAM roles shipped, and Guardway deleted the stored key. They show Needs migration and keep their discovered agents. To switch:

Create the role (steps above) in the same AWS account.
On the connection, click Switch to IAM role, paste the Role ARN and region, and click Verify & switch.

The connection, its name and its agents are kept. You can then deactivate the old access key and delete the IAM user in AWS.

Limits

Bedrock Agents (Classic) have no MCP servers. AgentCore harnesses do: remote MCP servers and AgentCore Gateways.
Guardrails referenced by agents appear as metadata only. For a harness, Guardway reads the guardrail set on its Bedrock model; a guardrail passed only at invocation time isn’t visible.
An AgentCore runtime’s model and tools are defined in its code and aren’t listed.

SIEM Export

Forward your gateways’ logs to your own SIEM — in near real time, with a 30-day backfill so nothing is lost past the gateway’s retention. A destination is created once per organization and applies to the gateways you choose; events are formatted for the destination you pick and shipped straight from the gateway to your SIEM. Audit logs can go to your SIEM even though they never reach Guardway cloud.

SIEM Export lives under Settings → Integrations → SIEM Export. Add as many destinations as you need — for example one Splunk for security and one webhook for a data lake. An empty list shows No SIEM destinations yet. Add one to start forwarding gateway logs.

Destination types

Type	Delivery	Secret
Splunk HEC	HEC JSON over HTTPS	HEC token
Syslog (CEF)	CEF over TCP/TLS syslog	— (mutual TLS optional)
Syslog (LEEF)	LEEF over TCP/TLS syslog	— (mutual TLS optional)
Webhook (NDJSON)	NDJSON over HTTPS	Bearer token / HMAC key (optional)
Microsoft Sentinel	Logs Ingestion API	Entra app client secret
Datadog	Logs Intake v2	Datadog API key
Google SecOps (Chronicle)	Chronicle ingestion API	Service account JSON
AWS Security Lake (preview)	OCSF 1.3 Parquet to S3	— (IAM role)

OCSF is an output schema, not a separate destination type. Any JSON destination — Splunk HEC, Webhook, Microsoft Sentinel, Datadog, Google SecOps — can emit OCSF objects instead of Guardway’s native shape by switching Output schema to OCSF. AWS Security Lake is the exception: it always writes OCSF, as Parquet. Syslog (CEF/LEEF) is a text format and has no OCSF mode.

Common fields

Every destination shares these:

Field	Notes
Name	A label for the destination (e.g. `Corp Splunk`).
Type	One of the destination types above.
Output schema	Native (Guardway) (default) or OCSF. On any JSON type, OCSF ships each event as an OCSF object instead of Guardway’s native body. Not shown for syslog (text format) or AWS Security Lake (always OCSF).
Endpoint	The destination URL (see each type below). Hidden for Google SecOps (derives its host from the region) and AWS Security Lake (writes to S3).
Gateways	Which gateways forward to this destination. Leave all unchecked to forward from every gateway.
Event types	Which events to forward: Request logs, Guardrail events, Audit logs, System events, Anomaly events. Leave all unchecked to forward all non-audit event types.
Forward audit logs	Off by default. When on, audit events are forwarded — straight to your SIEM, never to Guardway cloud.
Include request/response payloads	Off by default. When off, prompt and response bodies stay on the gateway; only metadata is forwarded.
Enabled	Turns forwarding on or off without deleting the destination.

Each saved destination has Test (send a probe event through a chosen gateway) and Backfill 30d (resend up to 30 days of buffered events). Splunk, webhook and syslog destinations also offer Skip TLS certificate verification — only for self-signed receivers on a trusted network.

Splunk HEC

Endpoint — your HEC URL, e.g. https://splunk.example.com:8088.
HEC token — a Splunk HTTP Event Collector token.

Syslog (CEF) and Syslog (LEEF)

Endpoint — host:514 for plain TCP, or tls://host:6514 for TLS. There is no secret; mutual TLS is optional.

Webhook (NDJSON)

Endpoint — any HTTPS endpoint that accepts newline-delimited JSON, e.g. https://logs.example.com/ingest.
Auth — No auth / HMAC sign (Guardway signs each batch), Bearer token, or Splunk HEC token (sends Authorization: Splunk <token>, for an OCSF-over-HEC collector or a Splunk HEC endpoint fronting a raw sink). The secret is the token or HMAC key, and is optional.

Microsoft Sentinel

Guardway delivers through the Logs Ingestion API (a Data Collection Endpoint, a Data Collection Rule and an Entra app) — not the retiring Data Collector API.

Endpoint — the Data Collection Endpoint, e.g. https://<dce-name>.<region>.ingest.monitor.azure.com.
Directory (tenant) ID, Application (client) ID, DCR immutable ID, and Stream name (e.g. Custom-GuardwayEvents_CL) — from the Data Collection Rule and the app registration.
Entra app client secret — the gateway exchanges it for an Entra token on each batch.

The app registration needs the Monitoring Metrics Publisher role on the Data Collection Rule.

Datadog

Site — picks the intake host: datadoghq.com (default), datadoghq.eu, us3.datadoghq.com, and so on. A wrong site is the most common cause of a silent 403.
Endpoint — leave blank; set it only to point at a Datadog Agent proxy or private link.
Datadog API key — your Datadog API key.

Google SecOps (Chronicle)

Forward events into Google Security Operations (Chronicle). The Region sets the ingestion host automatically; the other fields come from your Google SecOps tenant (Settings → Profile → Organization Details).

Field	Notes
Region	US, Europe, London (`europe-west2`), Singapore (`asia-southeast1`), or Global (multi-region). Sets the ingestion host; only verified regions are offered.
Project ID	Your Google Cloud project, e.g. `my-gcp-project`.
Customer / instance ID	Your Chronicle customer/instance UUID.
Log type	The Chronicle log type to ingest as, e.g. `GUARDWAY_SECURITY`.
Namespace	Optional Chronicle namespace, e.g. `prod`.
Service account JSON	A full GCP service-account key file (`type: service_account`, with `client_email` and `private_key`). The service account needs the `chronicle.logs.import` permission.

The ingestion host is pinned to the region’s verified Chronicle host — us-chronicle.googleapis.com, europe-chronicle.googleapis.com, europe-west2-chronicle.googleapis.com, asia-southeast1-chronicle.googleapis.com, or chronicle.googleapis.com for Global — which the gateway reaches over outbound HTTPS. See Network Requirements.

OCSF output

Switch a JSON destination’s Output schema to OCSF and every event ships as an Open Cybersecurity Schema Framework object — a typed class with class_uid, category_uid, activity_id, type_uid, a normalized severity_id, metadata, and the original Guardway fields preserved under unmapped. It works on Splunk HEC, Webhook, Microsoft Sentinel, Datadog and Google SecOps; the OCSF object nests inside each vendor’s envelope (so Sentinel’s DCR, Datadog’s facets and the rest keep working) and ships bare for Webhook/SecOps. Class mapping — Guardway events map to stable OCSF classes:

Guardway event	OCSF class	`class_uid` / `type_uid`
Request log	API Activity	6003 / 600301
Guardrail event, Anomaly	Detection Finding	2004 / 200401
Audit log (authentication)	Authentication	3002 / 300201
Audit log (other admin change)	Account Change	3001 / 300199
System / gateway health	Base Event	0 / 0

type_uid = class_uid × 100 + activity_id, and Guardway’s 0–10 severity maps onto OCSF severity_id 1–6 (Informational → Fatal). The same mapping is emitted by both the gateway and the endpoint (gw-cli) forwarders, so a parser sees one contract regardless of source.

OCSF schema version (optional) — stamped into metadata.version; defaults to 1.3.0. Override it with this field on the destination.
Include the raw Guardway event — when on, the full native event is kept under unmapped.raw for lossless replay (prompt/response bodies still follow Include request/response payloads).

The older standalone OCSF (HTTP) destination type still works — it is treated as a Webhook with Output schema: OCSF. New OCSF destinations should pick their transport (Splunk HEC, Webhook, …) and switch the schema to OCSF.

AI operation profile (OCSF 1.9)

Turn on AI operation profile to enrich AI requests (API Activity, 6003) with the OCSF 1.9 ai_operation profile: ai_model (name, provider, version), message_context (prompt / completion / total tokens, and — only when Include request/response payloads is on — the prompt and response text), and ai_agent (the calling agent’s name). With the profile on, metadata.version defaults to 1.9.0 and metadata.profiles lists ai_operation. It applies to API Activity only; findings and other classes keep their AI context in unmapped.

AWS Security Lake

Preview. This destination writes OCSF Parquet to your S3 custom source today, but the guided IAM onboarding (a CloudFormation quick-create for the writer role and its external ID) is still being finalized. For early access, set up the writer role and S3 permissions with your Guardway contact.

Stream your gateways’ events into an AWS Security Lake custom source as OCSF 1.3 Apache Parquet in S3 — one OCSF class per object, partitioned by UTC event-day, the layout Security Lake expects. Unlike the HTTP destinations there is no endpoint URL and no secret: the gateway writes with its own AWS identity (instance profile / IRSA), optionally assuming a role you provide.

Field	Notes
AWS region	Region of the Security Lake collection bucket, e.g. `us-east-1`.
Security Lake S3 bucket	The Security Lake managed bucket, e.g. `aws-security-data-lake-us-east-1-xxxxx`.
AWS account ID	The account that owns the custom source (used in the partition path).
Custom source name	Your `CreateCustomLogSource` name (≤ 20 chars); objects land under `ext/<source>/…`.
S3 prefix, Provider role ARN, External ID, KMS key ARN	Optional — an extra key prefix, a role to assume (with its external ID) before writing, and an SSE-KMS key for the objects.

OCSF is pinned to 1.3 here (Security Lake rejects unknown versions), so the AI operation profile is not applied — AI context stays in unmapped. Create the Security Lake custom source with CreateCustomLogSource (AWS recommends one source per OCSF class), then point this destination at it.

How to configure (SIEM Export)

Open SIEM Export

Settings → Integrations → SIEM Export → Add destination.

Pick a type and enter its endpoint

Choose the destination Type, give it a Name, then fill in the endpoint and credentials for that type (see the sections above). To ship OCSF instead of the native shape, set Output schema to OCSF (and, for AI telemetry, turn on the AI operation profile).

Choose gateways and events

Select the Gateways that should forward (or leave them all unchecked to forward from every gateway) and the Event types to include. Turn on Forward audit logs or Include request/response payloads only if you need them.

Add and test

Click Add destination, then Test on the new row to send a probe event through a gateway. Use Backfill 30d to resend up to 30 days of buffered events.

Endpoint events

When you edit a saved destination, the Endpoint events panel lets that same destination also carry endpoint (gw-cli) security events: AI activity, AI security alerts, Findings, Posture changes, and Policy blocks. Select at least one — an empty selection forwards nothing (unlike gateway events). Include prompt previews & content is off by default (only metadata leaves the platform), and Also forward this gateway’s own events keeps gateway events flowing alongside the endpoint events.

Endpoint event delivery reaches internet-reachable SIEMs through Guardway cloud; private / on-premises destinations are served by the gateway relay (coming soon).

Limits

Request and response payloads are off by default — only metadata is forwarded unless you turn them on.
Backfill resends up to the last 30 days of buffered events.
Audit logs are forwarded only when Forward audit logs is on, and even then they go only to your SIEM, never to Guardway cloud.

Anthropic Compliance

Connect your Anthropic Compliance Access Key (or Admin API key) to surface your organization’s Activity Feed and compliance signal from Claude Enterprise alongside Guardway’s own gateway audit logs — the same value as SIEM Export, sourced from Anthropic.

Field	Notes
Key type	Compliance Access Key (full compliance API) reaches all of Anthropic’s `/v1/compliance/` endpoints; Admin API key (Activity Feed only)* reads just the Activity Feed and needs the `read:compliance_activities` scope.
API key	The Anthropic key itself (`sk-ant-...`). Stored server-side, encrypted at rest, and never returned to the browser.

How to connect (Anthropic Compliance)

Create a key at Anthropic

Create a Compliance Access Key in claude.ai, or an Admin API key in the Claude Console (Activity Feed only, with the read:compliance_activities scope). See the Anthropic Compliance API docs.

Connect in Guardway

Settings → Integrations → Anthropic Compliance → choose the Key type, paste the API key, then Test & Connect. Guardway validates the key against the Compliance API before saving it.

Once connected, the card shows Connected as your Anthropic organization, the key type, and when it was connected. Disconnect removes the stored key; you can reconnect at any time with a new key.

Slack

Route Guardway alert rules and operational signals to Slack channels so your team can respond to AI platform events in real time. Connect once per workspace; multiple workspaces are supported.

How to connect (Slack)

Add a workspace

Settings → Integrations → Slack → Add Slack workspace. Install the Guardway Slack app to the workspace and authorize it; Guardway returns you to the integration with the workspace Connected.

Route alerts to channels

In an alert rule, pick the Slack channel to deliver to. Messages include deep links back to the relevant Guardway view, so critical events can route straight to an on-call channel.

Test delivery

Use Send test on a connected workspace to post a sample message.

Each connected workspace shows a connected badge and a Disconnect action.

If you’d rather not install the app, expand Advanced: use an Incoming Webhook URL instead on the Connect step and Paste a webhook URL (https://hooks.slack.com/services/…). Guardway posts a test message to validate it before saving. A webhook delivers to the one channel fixed at install time on Slack’s side, so the channel picker in the alert dialog is disabled for webhook-mode workspaces.

Coming soon

Hub cards marked Soon: Okta, Jira, GitLab. Email support@guardway.ai to prioritize one.

Agents — inventory and findings.
Dashboard → Agents — org-wide agent metrics.
Topology — gateway → provider → model → agent graph.
Discovery — GitHub-powered repository scans.
Organizations — sync and scan the organizations the GitHub App can read.
Network Requirements — the hosts a gateway reaches, including the SIEM destinations you configure.

​What this is for

​The integrations hub

​Search and filters

​Card states

​Integration dialog

​GitHub

​What the App can access

​The GitHub screen

​How to connect (GitHub)

​Multiple GitHub accounts

​Pull request scanning

​Fix with an AI coding agent

​Disconnect

​Azure DevOps

​Fields

​How to connect (Azure DevOps)

​What Guardway does with it

​Scheduled scans

​Keep inventory in sync

​Pull request scanning

​Several organizations

​Rotate the secret

​Troubleshooting

​Remove

​Azure AI Foundry

​Connection state

​Limits

​How to configure (Azure AI Foundry)

​Required Azure permissions

​Microsoft Entra ID

​Connection state

​Required Microsoft Graph permissions

​Limits

​How to configure (Microsoft Entra ID)

​Amazon Bedrock

​How the role is trusted

​Required AWS IAM permissions

​How to configure (Amazon Bedrock)

​Without CloudFormation (console or Terraform)

​Connection state

​Updating an existing role (Update available)

​Migrating from access keys

​Limits

​SIEM Export

​Destination types

​Common fields

​Splunk HEC

​Syslog (CEF) and Syslog (LEEF)

​Webhook (NDJSON)

​Microsoft Sentinel

​Datadog

​Google SecOps (Chronicle)

​OCSF output

​AI operation profile (OCSF 1.9)

​AWS Security Lake

​How to configure (SIEM Export)

​Endpoint events

​Limits

​Anthropic Compliance

​How to connect (Anthropic Compliance)

​Slack

​How to connect (Slack)

​Coming soon

​Related

What this is for

The integrations hub

Search and filters

Card states

Integration dialog

GitHub

What the App can access

The GitHub screen

How to connect (GitHub)

Multiple GitHub accounts

Pull request scanning

Fix with an AI coding agent

Disconnect

Azure DevOps

Fields

How to connect (Azure DevOps)

What Guardway does with it

Scheduled scans

Keep inventory in sync

Pull request scanning

Several organizations

Rotate the secret

Troubleshooting

Remove

Azure AI Foundry

Connection state

Limits

How to configure (Azure AI Foundry)

Required Azure permissions

Microsoft Entra ID

Connection state

Required Microsoft Graph permissions

Limits

How to configure (Microsoft Entra ID)

Amazon Bedrock

How the role is trusted

Required AWS IAM permissions

How to configure (Amazon Bedrock)

Without CloudFormation (console or Terraform)

Connection state

Updating an existing role (Update available)

Migrating from access keys

Limits

SIEM Export

Destination types

Common fields

Splunk HEC

Syslog (CEF) and Syslog (LEEF)

Webhook (NDJSON)

Microsoft Sentinel

Datadog

Google SecOps (Chronicle)

OCSF output

AI operation profile (OCSF 1.9)

AWS Security Lake

How to configure (SIEM Export)

Endpoint events

Limits

Anthropic Compliance

How to connect (Anthropic Compliance)

Slack

How to connect (Slack)

Coming soon

Related