Deny Events

Firefly's Deny Events surface cloud actions that were blocked by governance policies — such as AWS Service Control Policies (SCPs), Azure Policy denials, and GCP Organization Policy constraints. By consolidating these denied actions into the Event Center, Firefly gives you a clear view of who tried to do what, which policy blocked it, and how to remediate it.

Think of Deny Events as a window into your guardrails in action: it's where you go to answer "What did my policies just stop, and was that the right call?".

Overview

Deny Events are a dedicated category within the Event Center. Each entry corresponds to a cloud API action that was rejected by an organizational governance policy, displayed in the same chronological timeline as other events. Entries include details like timestamp, the principal who attempted the action, the target asset, the action attempted, and — where available — the specific policy that caused the denial.

This gives you a unified view of policy enforcement across AWS, Azure, and GCP, helping you tell apart legitimate guardrail hits from misconfigured policies that are blocking valid work.

Key Benefits

• Policy Visibility: See exactly which SCP, Azure Policy, or GCP Org Policy constraint blocked a given action — no more digging through provider consoles.

• Faster Troubleshooting: When a developer reports "I can't do X", trace the denial straight to the responsible policy.

• Misconfiguration Detection: Spot policies that are too broad or incorrectly scoped by reviewing the actions they're blocking.

• Compliance Evidence: Demonstrate that your preventative guardrails are actively enforcing intended controls.

• AI-Powered Remediation: Get contextual recommendations directly inside the Event Center to resolve denials safely.

Supported Providers

Firefly currently supports Deny Events from the following sources:

AWS — Service Control Policies (SCPs)

Captures actions denied by SCPs attached to AWS Organizations, OUs, or accounts. SCPs operate at the organizational level and block API calls before they reach the target service, regardless of the principal's IAM permissions.

When a user or role attempts an action that violates an SCP — for example, creating an EC2 instance in a restricted region — Firefly logs a Deny Event with the denied action, the principal, and the target resource.

Azure — Azure Policy

Captures actions denied by Azure Policy assignments with deny effect, applied at management group, subscription, or resource group scope.

For Azure, Firefly enriches the displayed event with additional details parsed from the raw event payload, including:

• Policy Name: The human-readable name of the Azure Policy definition that triggered the denial.

• Policy Assignment: The specific assignment (and scope) responsible for the block.

• Redirect to Policy: A direct link from the event to the policy definition in the Azure portal, so you can review and adjust it in context.

GCP — Organization Policy Constraints

Captures actions denied by GCP Organization Policy constraints (both predefined boolean/list constraints and custom constraints). Firefly surfaces the constraint that blocked the action and, where available, the policy bindings responsible.

Capabilities

Filtering Deny Events

Deny Events appear alongside other Event Center entries and can be isolated using the Event Type filter set to Deny. They can be further refined using the standard Event Center filters:

• Data Source: Narrow to AWS, Azure, or GCP.

• Action Type: Focus on denied creates, deletes, updates, etc.

• Asset Type: Investigate denials against specific resource types.

• Owner / Principal: See which user, role, or service account was blocked.

• Location: Filter by region or scope.

• Timeframe: 24 hours, 7 days, 30 days, or a custom range.

AI Recommendations

Each Deny Event includes an AI Recommendation panel below the event details. The recommendation analyzes the denied action together with the responsible policy and surfaces:

• Policy Identification: Which policy or constraint caused the denial, summarized in plain language.

• Root Cause Explanation: Why the action was blocked, including the conditions or scope that triggered the deny.

• Suggested Remediation: Concrete next steps — for example, adjusting the policy scope, exempting a specific principal, or modifying the offending request — so you can either unblock legitimate work or confirm the deny was correct.

The recommendation is contextual to the specific event and provider, and is generated on demand from the event's raw payload and the associated policy definition.

Event Metadata

Each Deny Event includes the following information:

• Date: Timestamp of the denied attempt.

• Provider: AWS, Azure, or GCP.

• Principal / Owner: The user, role, or service account that attempted the action.

• Action: The specific API operation that was denied (e.g., ec2:RunInstances, Microsoft.Storage/storageAccounts/write).

• Target Asset: The resource the action was attempted against, where identifiable.

• Region / Scope: Where the attempt occurred.

• Source IP / User Agent: Origin of the request (where provided by the cloud provider).

• Policy Details (Azure; AWS & GCP where available): Name and identifier of the policy that triggered the denial, plus a redirect link to the policy in the provider console.

• Raw Event Payload: The underlying cloud audit log entry for deeper investigation.

Best Practices

Daily Operations

• Review Deny Events alongside other Event Center activity to catch policy misconfigurations early.

• Investigate repeated denials from the same principal — they often indicate either a missing exemption or an attempted misuse.

Policy Tuning

• Use the AI Recommendation to decide whether a deny is correct or whether the policy needs to be scoped more narrowly.

• Track denial patterns over time to identify policies that block more legitimate work than malicious activity.

Compliance and Auditing

• Export filtered Deny Events for evidence that preventative guardrails are active and enforcing.

• Correlate denials with change requests to demonstrate that out-of-policy actions are being stopped before impact.

Deny Events turn silent policy denials into a visible, actionable signal — making your preventative controls observable, debuggable, and easier to evolve over time.