Skip to main content

Documentation Index

Fetch the complete documentation index at: https://redberrylabs.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

Engineering controls are the concrete practices and safeguards you put in place to reduce the likelihood and severity of AI agent failures. When Redberry Labs underwrites your agent, we evaluate six controls. Strong controls lower your risk score and your premium. They also serve as a defensible record when a claim arises — demonstrating that you operated responsibly and took reasonable precautions to prevent harm.

​
Permissioning

Your agent uses least-privilege access — it has only the permissions it needs to perform its defined function, and no more.
Redberry evaluates whether your agent operates under a tightly scoped permission model. Blanket admin tokens and over-provisioned service accounts are the most common source of unnecessary exposure — they expand what an agent can do if it is compromised or behaves unexpectedly. We look for role-based access that is tied to the agent’s specific tasks, not inherited from a generic service account. We also check whether permissions are reviewed and updated as the agent’s function changes over time.

​
Tool safety

Every external action the agent can invoke uses validated schemas, sandboxed execution, and input/output filtering.
Tools are the primary vector through which an agent can cause harm outside of its own outputs. Redberry evaluates whether every tool in your agent’s toolkit has a validated schema defining exactly what inputs it accepts, whether tool execution runs in an isolated environment that limits blast radius, and whether all inputs going into a tool and all outputs coming out of it are filtered and logged. Unvalidated tool calls — particularly to payment systems, external APIs, or communication channels — are one of the highest-risk configurations we encounter.

​
Human-in-the-loop for risk actions

High-stakes actions have defined escalation paths and require human approval before execution.
Not every action your agent takes needs a human to review it. But for actions that are irreversible, financially significant, or that affect customer data, a human approval gate substantially reduces operational failure and financial error risk. Redberry evaluates whether you have identified which actions in your agent’s repertoire are high-stakes, whether escalation paths are defined and tested, and whether approval gates are enforced at the system level — not just by the agent’s own instructions, which it could theoretically be prompted to bypass.

​
Data minimisation

Your agent accesses only the data it needs for each task, and does not retain sensitive information beyond the scope of that task.
Data minimisation limits the exposure surface in the event of a data breach or an unexpected output. Redberry evaluates whether your agent retrieves only the data it needs at the point it needs it, rather than preloading large datasets into its context. We also look at whether the agent writes sensitive data to persistent caches, logs, or memory stores. Agents that accumulate sensitive data over time — PII, financial records, health information — create compounding data exposure risk with every task they perform.

​
Auditability

Every decision, tool call, and state change the agent makes is logged in a structured, tamper-evident format.
Auditability is what makes a claim reviewable and a post-incident investigation possible. Redberry evaluates whether your agent produces structured logs — not freeform text output, but machine-readable records that capture what the agent decided, which tools it called, what inputs those tools received, and what outputs they returned. Logs should be timestamped and stored in a way that prevents tampering after the fact. We also look for whether your logging is comprehensive enough to reconstruct the agent’s full decision path for any given task.

​
Model and prompt governance

Your agent runs on a version-pinned model, your system prompt is reviewed and change-controlled, and updates go through a formal change-management process.
Silent drift is one of the most underappreciated sources of AI insurance risk. An agent that passes underwriting can become materially riskier if its underlying model is silently swapped for a newer version with a larger context window, or if its system prompt is edited without review. Redberry evaluates whether you pin your agent to a specific model version rather than tracking a rolling “latest” release, whether your system prompt is stored in version control and reviewed before changes are deployed, and whether you have a change-management process that prevents undisclosed modifications from reaching production.
Redberry evaluates all six controls at underwriting time. The same controls are then monitored continuously via the SDK after your agent is deployed. If a control degrades after deployment — for example, if permissions are broadened, a new unvalidated tool is added, or logging is disabled — and Redberry is not notified, this may affect the terms of your coverage. Keep the SDK active and notify Redberry of any significant changes to an insured agent. See Continuous Monitoring for details.