AI Security and Governance
TBW / AI security and governance
Secure AI starts at the trust boundary
Design identity, data handling, tool permissions and oversight together—before an AI system reaches production. These are reference controls to scope and validate for each environment, not a claim that they are already installed.
Eight layers, one accountable architecture
The layers reinforce one another. A prompt filter cannot replace authorization, and an audit log cannot prevent an unsafe action by itself.
Identity
Know who or what is requesting access; use distinct human, service and agent identities.
Authorization
Scope permissions to the task and recheck them before sensitive actions.
Data Protection
Classify inputs and outputs; apply retention, redaction and DLP appropriate to the data.
Model Security
Approve model endpoints, versions and data-handling terms; test outputs and fallback paths.
Agent Security
Constrain goals, memory, step budgets and human approval for consequential actions.
Tool / MCP Security
Allowlist connectors and schemas; isolate credentials and validate every tool call server-side.
Monitoring and Audit
Log decisions and actions with appropriate privacy controls; alert on anomalous use.
Governance
Assign ownership, review exceptions and revisit policies as systems and risks change.
Threats worth designing for
Threats differ by workflow and data sensitivity. The following are design questions and possible controls—not a guarantee of prevention.
Prompt injection
A user message can attempt to override intended instructions; enforce authorization outside the model.
Indirect prompt injection
Retrieved pages, files or tool results can carry hostile instructions; treat them as untrusted data.
Data leakage
Prompts, responses or logs may expose sensitive material; classify, minimize and inspect flows.
Over-permissioned agents
Broad credentials expand the blast radius of mistakes; use least privilege and short-lived scopes.
Tool misuse
A valid tool used with unsafe arguments can cause harm; validate parameters and gate writes.
RAG poisoning
Compromised source documents may bias answers or inject commands; track provenance and review ingestion.
Secret exposure
Keys in prompts, logs or client code can leak; keep secrets server-side and rotate on exposure.
Excessive agency
Long unconstrained loops can multiply errors; set limits, timeouts and approval checkpoints.
Shadow AI
Unmanaged AI use can bypass data policies; offer approved paths and visibility.
Unauthorized models/services
Unreviewed endpoints may have unsuitable data handling; maintain an approved service inventory.
For bounded agent workflows, see Agentic AI and identity and permissions guardrails.
Shadow AI: two different paths
Illustrative technical comparison. An approved gateway requires actual policy ownership, integration and testing; the diagram does not represent a live TBW service.
Unmanaged path
- Employee
- Public AI
- Corporate data shared
Without a reviewed service boundary, users may paste sensitive material into unapproved tools. Data handling and retention can be unclear.
Governed design
- Employee
- Approved AI gateway
- DLP / policy
- Approved models / tools
- Audit
Route access through identity and policy, check data before release, limit destinations and retain a proportionate record for review.
Explore data protection in AI workflows and private AI boundaries.
From discovery to continuous review
- 01 Discover
- 02 Assess
- 03 Architect
- 04 Control
- 05 Validate
- 06 Monitor
Inventory data, users and AI endpoints; assess misuse paths; design control ownership; implement scoped controls; test adversarial and failure cases; then monitor and revisit changes. See consulting for an engagement path.
Explore adjacent architecture
Make the controls fit your environment
Bring your data paths, identity model and proposed AI use cases to a scoping conversation. No certifications, regulatory outcomes or deployment guarantees are implied.