Security requirements written as general statements, "the feature should handle data securely," give a development team nothing to actually check against once the feature's built. Security requirements that genuinely shape what gets built need the same specificity as functional requirements: concrete, checkable statements about data, action authority, and failure behavior that a developer can implement against and a reviewer can verify.
Data requirements: what enters and what is minimized
Write specific requirements about what data the feature's model context will include: name the specific data sources and fields the feature's task needs, and explicitly state what shouldn't be included even if it's technically available, following the data minimization principle running throughout this content series. A requirement like "include only the customer's current order details, not their full order history" is checkable during implementation and review. "Handle customer data appropriately" is not, and never will be.
Access requirements: whose permissions govern retrieval and tools
Write a specific requirement stating whose permissions govern every retrieval and tool call: the requesting user's actual authorization, not some shared service credential. If the feature genuinely needs to access data across multiple permission boundaries, say so explicitly and require the specific authorization logic that makes it safe, rather than leaving the requirement implicit and letting implementation default to whatever access happened to be technically convenient at the time.
Action requirements: what the feature can do and its limits
For any feature with tool access, write specific requirements for each tool: what operation it performs, what limits apply, transaction amounts, rates, destinations, whether approval is required above a stated threshold. Name these limits as specific numbers or conditions where possible, "requires approval above five hundred dollars," rather than vague statements like "should have appropriate limits," which give an implementer nothing concrete to build against.
Content handling requirements: what is trusted and what is not
Write an explicit requirement naming which content sources the feature will treat as trusted instructions versus untrusted data, following the instruction hierarchy covered in prompt security guidance. This requirement should be specific enough that a developer implementing prompt structure knows exactly which sources need explicit untrusted-content handling, rather than figuring it out implicitly during implementation with no documented guidance to follow.
Output handling requirements: what gets validated before it acts
For any feature whose output reaches a sensitive destination, a database, a rendered page, another system, write a specific requirement naming what validation has to happen before that output takes effect: format validation appropriate to the destination, and any business rule checks that apply regardless of the output's format validity. This requirement should specify what happens when validation fails, rejecting the action rather than proceeding with a degraded or partial result.
Failure behavior requirements: what happens when a dependency is down
Write an explicit requirement for how the feature behaves when a security dependency, an authorization check, an approval service, goes down: specify that the default is to deny or hold sensitive actions, not proceed as if the check had passed. This requirement is frequently missing from AI feature specifications entirely, which leaves the actual failure behavior to whatever an implementer defaults to under time pressure, often the less safe option of proceeding rather than blocking.
Logging and monitoring requirements: what gets recorded
Write a specific requirement naming what the feature must log for every significant interaction: identity, policy decisions, tool calls, and outcomes, following the metadata-focused logging guidance covered elsewhere, plus any AI-specific monitoring signals relevant to the feature's specific risk profile, like denial rate tracking for a feature with meaningful action capability.
Review requirements against the feature's risk classification
Before finalizing requirements, check that their rigor matches the feature's risk classification, covered in governance guidance: a low-risk internal tool needs lighter requirements than a high-risk customer-facing agent, and writing requirements proportional to actual risk keeps the requirements process itself efficient instead of becoming a uniform burden regardless of a feature's actual risk level.
Where TELEON fits
For requirements around action authorization, limits, and approval, TELEON's policy enforcement, applied through the gateway or supported middleware, provides a direct implementation path once these requirements are specified, and its audit trail supports verifying logging requirements are actually satisfied in the running system.
Writing the specific requirements themselves, tailored to each feature's actual data, tools, and risk profile, remains work that has to be done by whoever owns that feature's security requirements before implementation begins.
A short checklist
- Write specific data requirements naming what enters context and what
is deliberately excluded.
- Write access requirements specifying whose permissions govern every
retrieval and tool call.
- Write action requirements with specific limits and approval thresholds.
- Write content handling requirements naming trusted versus untrusted
sources explicitly.
- Write output handling requirements specifying validation before
sensitive effect.
- Write failure behavior requirements specifying deny-by-default for
security dependencies.
- Write logging requirements naming what must be recorded.
- Scale requirement rigor to the feature's risk classification.
Security requirements for an AI feature earn their value through specificity, concrete statements about data, action, and failure behavior that a developer can build against and a reviewer can verify, rather than general aspirational statements that leave the actual implementation undefined until it is too late to cheaply change.