Ideogram Enterprise RbacBLOCK

Model-agnostic agent-skills platform with a harness-free canonical layer, verified adapters, and the ccpi package manager. Explore at tonsofskills.com.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: ideogram-enterprise-rbac
description: >-
  Map Ideogram Owner, Admin, and Member roles to application-owned tenant, budget, key, media, publishing, and audit permissions. Use when designing or reviewing enterprise access control. Trigger with "design Ideogram RBAC", "audit Ideogram team roles", or "separate Ideogram duties".
allowed-tools: Read,Glob,Grep,Write,Edit
argument-hint: "<team> <application-roles> <environment>"
version: 1.11.0
license: MIT
author: Jeremy Longshore <[email protected]>
tags: [saas, ideogram, access-control]
model: inherit
effort: high
compatibility: "Designed for Claude Code; team and key mutations require authorized administrators"
---
# Ideogram Enterprise Access Control

## Overview

Keep Ideogram team administration distinct from application authorization. Vendor roles govern a shared team boundary, while the application must enforce tenant, use-case, spend, upload, generation, review, publication, retention, and incident permissions.

## Prerequisites

- Ideogram team inventory, role holders, keys, billing owner, environments, and emergency contacts.
- Application identity provider, tenant model, service identities, permission catalog, and audit requirements.
- Joiner, mover, leaver, key rotation, access review, and break-glass processes.

## Current Contract

Ideogram documents Owner, Admin, and Member team roles. Team members share keys, credits, and billing context; separate keys do not inherently provide per-user or per-environment vendor budgets. Avoid inventing finer Ideogram permissions that the application must actually enforce.

## Authentication

Store each server-side `IDEOGRAM_API_KEY` in the approved secret manager and send it only as `Api-Key` to `https://api.ideogram.ai`. Users authenticate to the application; only constrained service identities reach the vendor adapter.

## Instructions

1. Inventory vendor role holders, keys, credit authority, environments, application roles, service identities, and asset stores.
2. Define vendor Owner, Admin, and Member responsibilities from current first-party documentation.
3. Build an application permission matrix for request, upload, transform, train, spend, review, publish, export, delete, key administration, and incident actions.
4. Enforce tenant and environment scope at the gateway, queue, async state, webhook, storage, and publisher.
5. Separate requester, approver, publisher, billing administrator, key administrator, and auditor where risk warrants.
6. Test denied access, cross-tenant object access, wrong-environment key use, leaver removal, key rotation, and break-glass expiry.
7. Record periodic review evidence and remediate stale identities or excessive service authority.

## Tool Discipline

Use Read, Glob, and Grep for manifests, policy, identity mappings, and audit evidence. Use Write and Edit for approved policy or tests. Do not change team members, roles, keys, billing, or production identities by invocation alone.

## Approval Boundaries

Require authorized administrators for vendor membership, role, key, and billing changes. Require application and data owners for tenant permissions, publication, retention, and deletion. Break-glass access must expire and be reviewed.

## Error Handling

- Do not claim application permissions are enforced by a coarse vendor team role.
- Revoke or rotate authority after a leaver or credible key exposure, then verify every consumer.
- Deny ambiguous tenant or environment context before queueing paid work.

## Output

Return vendor-role and application-permission matrices, identities, scopes, separation-of-duty findings, tests, exceptions, owners, remediation, review date, and rollback. Exclude keys and personal or media content.

## Examples

- A Member may use the shared team context, while only an application Publisher can release an approved tenant asset.
- A billing Admin controls credit; a service identity receives only bounded generation authority through the gateway.

## Validation

Test every allow and deny edge, cross-tenant and cross-environment access, deprovisioning, rotation, audit completeness, and break-glass expiry. Confirm no role grants direct browser access to the vendor key.

## Resources

- [Current first-party evidence map](references/official-docs.md) — use the dated endpoint, webhook, billing, team, and training links as the contract index for this workflow.
- Recheck the endpoint-specific page and current OpenAPI description before relying on an enum, limit, beta feature, or lifecycle claim.
- Record live observations as environment-specific evidence, not as universal vendor guarantees.

BLOCKgrade D · trust 69/100 Do not install this without reading the findings. The audit found something that could harm you or your machine.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (1)

Store each server-side `IDEOGRAM_API_KEY` in the approved secret manager and send it only as `Api-Key` to `https://api.ideogram.ai`. Users authenticate to the application; only constrained service ide

Gates applied: critical_finding, no_behavioural_pass, undeclared_transfer.