Investigate requests and recover access

All Gateway guides

Read decisions and outcomes separately

Allowed means the policy permitted forwarding. Flagged means Monitoring found a policy violation but forwarded the request. Blocked means Gateway stopped forwarding. A completed scan elsewhere in Foo Guard is not a Gateway decision.

Response received means the upstream finished a valid protocol response; the tool can still report an application error. A streamed tool response is received only after that stream finishes. Not sent means Gateway blocked the request. Awaiting outcome means the outcome has not been recorded yet. Outcome uncertain means execution may have occurred, including when a stream breaks before it finishes. Never automatically retry the underlying tool call after an uncertain outcome. Use unique tool-call IDs across client restarts; duplicate IDs are rejected after reservation.

Arguments and responses are processed in memory but are not retained in request history. History contains the server, agent, and tool identifiers, plus rule, mode, decision, policy version, outcome and timestamps. Administrators' reasons are recorded for administrative changes; do not put secrets in them.

Investigate and respond

Open Gateway → Requests, filter by agent, exact tool name or decision, and select Investigate. Review the rule and outcome before choosing an action:

• Mark reviewed to dismiss the concern from the loaded in-app alert view.
• Add an expiring exception for this agent and tool when the access is justified.
• Add a deny rule for this agent and tool when it should violate policy.
• Block the agent to stop its future requests in both modes.

Use Load older requests for older history. Refresh explicitly to see new activity. The Team Agent behavior view compares the last 24 hours against the preceding six days of retained Gateway request metadata, independently of request filters. It needs at least 100 successful allowed requests across three UTC days for each agent and policy revision before reporting deviations. New policy revisions learn separately.

It flags a tool absent from that baseline after at least three recent calls, and a five-minute burst after at least 20 calls and three times the previous peak. Each signal shows supporting counts, an example request receipt, and an investigation action. These are deterministic monitoring heuristics, not a probability of compromise or a security score. Expected workflow changes can explain them; a previously allowed request is not proof of safety.

Refresh explicitly to recompute the report. Requests beyond the seven-day window are excluded. Reports are bounded to 10,000 retained requests per workspace; if the window is incomplete, signals are withheld. No request arguments or results are used. Owners and administrators can approve a baseline from Agent behavior. Review the successful-request count, UTC-day coverage, tool set and five-minute peak, then confirm. The server recomputes the exact reviewed snapshot and rejects changed evidence or reviews older than 15 minutes. The reference remains fixed as new requests arrive. A policy revision change requires review before comparisons resume.

Use rolling baseline clears the approved reference after confirmation; it does not delete requests or restart history collection. Approval, replacement and reset are recorded in the organization audit log. Concurrent changes require refresh. Members can see comparisons but cannot approve or reset. Saved references remain available when their original request window ages out. Incomplete recent history still suppresses signals.

Behavioral webhook alerts and blocking based on a behavioral score are not implemented. Existing policy enforcement and request alerts continue independently.

For alerts without an open browser, configure signed webhook notifications. They cover selected blocked, flagged and uncertain request events. Volume summaries and learned anomaly detection do not currently produce webhook events.

Connected account, unsuccessful operation

A connected account and successful capability discovery do not establish permission to run every operation. Providers can require additional permissions at call time.

Gateway returns specific recovery guidance for an explicit OAuth scope challenge, rejected credentials, denied access, or provider rate limiting. It exposes only recognized permission labels and the request receipt ID, never the upstream response body, token, or arbitrary authorization URL. Unrecognized scopes are not displayed; an administrator should consult the provider’s documentation.

• Additional permissions: Have a workspace administrator review the requested access before changing the connection’s scopes. Reconnecting with unchanged scopes will not resolve the mismatch. Scope changes require a fresh connection review and member consent.
• Credentials rejected: Reconnect your account under Gateway → Connection.
• Access denied: Check provider account access and organization restrictions as well as configured permissions.
• Rate limited: Wait before starting another request.

Gateway never automatically retries these calls. The history receipt conservatively remains uncertain because the request reached the upstream transport; it does not claim an operation succeeded or was never sent. Match the receipt ID from the error with request history before deciding whether to submit a new call. Existing historical errors cannot be reclassified without evidence.