Spoken prompt injection from background audio

TL;DR: Treat background speech, quoted instructions, and retrieved text as untrusted content. They may influence a proposed action, but permission must come from independent current authority bound to the exact subject, session, intent, policy, state version, and deadline.

---

A television speaks while a caller is explaining a delivery preference. The recognizer includes some of that speech in its transcript, and a model proposes an action the caller never authorized. The dangerous transition is the promotion of recognized content into business permission.

You can test that boundary without pretending to have observed a real background-audio incident. This guide provides a defensive synthetic replay manifest and a small deterministic policy function. It checks proposed actions against independently supplied authority and emits the actual replay dispositions. It does not detect every injection, render speech, identify speakers, or execute business actions.

The workflow-enforcement guide explains the broader separation between conversational interpretation and application control. Here the first useful result is narrower: a transcript cannot create a grant, and a proposed action cannot use a grant belonging to another current intent.

Table of contents

1. Define the boundary before naming an attack
2. Separate speech from permission
3. Limit the action vocabulary
4. Bind exact intent at the gate
5. Own the approved material values
6. Run the defensive replay reference
7. Interpret the negative controls
8. Recheck after asynchronous work
9. Keep detectors in a supporting role
10. Evaluate speech and policy separately
11. Preserve useful evidence without raw leakage
12. Choose an enforceable control matrix
13. Keep credential verification outside the transcript
14. Turn the manifest into an honest test plan
15. Review failure paths as carefully as the allow path
16. Frequently asked questions
17. Start with a bounded authority test

Define the boundary before naming an attack

Spoken prompt injection describes instruction-like content entering a voice application's interpretation path and attempting to redirect behavior. Background audio is one possible source. A caller quoting another person, a retrieved document, or a tool response can create a similar data-versus-authority problem after the content becomes text.

OWASP's 2025 prompt-injection entry describes direct and indirect influence from untrusted inputs and the limitations of model-level mitigations. That source supports a general threat model. It does not establish an attack rate for telephone calls or prove that a particular background recording bypasses your current system.

Keep the observable stages separate: captured audio, recognized transcript, proposed interpretation, independent authorization, and actual downstream action. A transcript containing a troubling instruction is evidence about content. A tool proposal is evidence about model behavior. Neither proves that an unauthorized side effect occurred.

The observability guide helps organize those distinctions. Record a bounded reason at the action boundary and retain appropriate test provenance, rather than calling every suspicious transcript an executed attack. A local denial is also not proof that every other tool or export path has equivalent controls.

For this article, every replay phrase is an invented synthetic description. The manifest contains no real customer recording and no operational attack campaign. Audio rendering and acoustic robustness remain explicitly untested. This gives you a reproducible policy test while keeping the claims aligned with what the code actually executes.

Separate speech from permission

A recognizer answers a content question: which words did the audio appear to contain? An authorization service answers an authority question: may this principal perform this exact operation now? Combining those answers in one untrusted text field makes it difficult to determine who is actually permitted to change business state.

The caller-authentication guide treats identity evidence separately. A spoken declaration of a name or role does not establish control of a credential. Likewise, a transcript saying an action is approved cannot set a trusted approval flag in the application.

Origin labels can help debugging and evaluation, but they are not authentication. A diarization label, channel annotation, or classifier prediction can be wrong. The policy demonstration therefore denies a request without independent authority regardless of whether its synthetic origin is caller, quoted, background, retrieved, or missing.

The shared-phone guide explains why phone context is also insufficient to identify a business principal. Do not treat the arrival of audio on a familiar call as proof that every audible instruction belongs to the authorized person or current task.

Maintain a separate trusted input path for current subject, session, allowed operation, approved intent, and revocation evidence. The model can propose values for examination. It cannot write that authority record by returning an object that contains a convenient verified field.

Limit the action vocabulary

The smaller the exposed action surface, the easier it is to define and test its authority boundary. A delivery-preference operation has a bounded resource and a short set of accepted values. A generic command, unrestricted URL fetch, or arbitrary message sender introduces additional destinations and effects that require their own authorization contracts.

OWASP's excessive-agency entry connects risk to excessive functionality, permissions, and autonomy. Its mitigation guidance supports least privilege and downstream authorization. It does not promise that reducing tool count makes model output trustworthy.

The reference exposes one teaching action with one synthetic resource and two material values. Its factory rejects unexpected fields, including a caller-supplied authority field. The decision function revalidates that bounded proposal even if somebody manually constructs the dataclass instead of using the factory.

The speculative tool-calling guide explains why a model's eagerness to prepare work must not become permission to perform side effects. You may prepare a proposal early under a declared contract. The final action still needs current independent authorization and exact approved values.

Keep read access and write access distinct too. Retrieving a delivery option is not the same capability as changing it. A tool result describing the next possible action should remain data, even when its wording is imperative or it includes a plausible explanation of why the change would be useful.

Bind exact intent at the gate

An approval should identify the material operation it covers. Subject and session alone are insufficient when the same conversation can contain several resources or corrections. Bind the action, resource, and value to the grant, and compare that binding with the current authoritative intent before admitting the action.

The example computes a digest from an explicitly ordered representation of the proposal's material scalar fields. This digest is an equality aid. It is not a signature, a credential, encryption, or proof that the caller approved anything. A trusted external verifier and confirmation controller must supply that evidence.

OWASP's authorization cheat sheet recommends default denial and permission checks on every request. Apply that guidance at the authoritative service boundary. A successful client-side comparison is useful evidence about local admission, but another process or direct API caller can bypass a client-only check.

The stale tool-result guide explains the related business-version boundary. A grant for an earlier state does not automatically authorize a proposal against changed inventory or account facts. The local gate compares the expected state version with the supplied current version rather than substituting a recent timestamp.

The fixture uses zero as a valid initial policy epoch and state version. Missing evidence is represented separately. Exact integer guards reject booleans and malformed numeric metadata, so a truthy value cannot accidentally stand in for a legitimate version.

Own the approved material values

A proposal can change without a visible new model response if the application keeps an alias to a mutable dictionary. A formatter, repair routine, or adapter might modify that dictionary after approval. The result is an action whose values differ from the values the approval originally covered.

The reference copies its supported scalar fields into a frozen dataclass. Its fields are strings, so no nested mutable container remains inside the proposal. The fixture changes the original input dictionary and verifies that the saved proposal remains unchanged.

Python's dataclass documentation defines frozen field assignment behavior. Frozen does not recursively freeze arbitrary nested values, and annotations do not enforce runtime types. That is why the factory performs concrete shape and value checks rather than relying on an annotation to reject an authority dictionary.

The literal identifier guide illustrates the same ownership concern for captured characters. The exact value you submit must be the exact current value that was examined, rather than a nearby display surface or a shared object that has since been repaired.

A material correction creates a new proposal and invalidates the old grant's intent binding. Do not update the approved object in place and continue calling it approved. The test explicitly proposes the alternate delivery value and expects the original grant to fail the binding comparison.

Run the defensive replay reference

Run the entire fence with Python's standard library. It contains a bounded action schema, immutable evidence records, a pure decision function, negative controls, and an emitted replay manifest. The only authority used in the positive control is explicitly constructed synthetic fixture evidence.

In an integration, Grant and Current must come from trusted adapters, not deserialization of model-generated fields. The code does not verify credentials or maintain an authoritative session store. Treat its construction of those records as test setup, not as an authentication implementation.

from dataclasses import dataclass, FrozenInstanceError, replace
from hashlib import sha256
import json

def integer(value):
    return type(value) is int and 0 <= value <= 1000000

@dataclass(frozen=True)
class Proposal:
    action: str
    resource: str
    value: str

def proposal(fields):
    if type(fields) is not dict or set(fields) != {'action', 'resource', 'value'}:
        raise ValueError('unsupported proposal shape')
    if (not all(type(v) is str for v in fields.values()) or
            fields['action'] != 'set_delivery_preference' or
            fields['resource'] != 'synthetic-order' or
            fields['value'] not in ('pickup', 'delivery')):
        raise ValueError('unsupported material value')
    return Proposal(fields['action'], fields['resource'], fields['value'])

def digest(p):
    return sha256(json.dumps([p.action, p.resource, p.value],
                             separators=(',', ':')).encode()).hexdigest()

@dataclass(frozen=True)
class Grant:
    subject: str
    session: str
    intent: str
    epoch: int
    version: int
    deadline: int

@dataclass(frozen=True)
class Current:
    subject: str
    session: str
    intent: str
    epoch: int
    version: int
    revoked: bool = False

def decide(p, grant, current, now):
    if not integer(now):
        return 'deny:invalid-clock'
    if type(current) is not Current or type(current.revoked) is not bool:
        return 'deny:invalid-authority'
    if current.revoked:
        return 'deny:revoked'
    if grant is None:
        return 'deny:independent-grant-required'
    if type(grant) is not Grant or type(p) is not Proposal:
        return 'deny:invalid-evidence'
    try:
        proposal({'action': p.action, 'resource': p.resource, 'value': p.value})
    except ValueError:
        return 'deny:invalid-proposal'
    if not all(integer(v) for v in (grant.epoch, grant.version, grant.deadline,
                                     current.epoch, current.version)):
        return 'deny:invalid-evidence'
    if now >= grant.deadline:
        return 'deny:expired'
    if not (grant.subject == current.subject == 'synthetic-subject' and
            grant.session == current.session == 'synthetic-session' and
            grant.intent == current.intent == digest(p) and
            grant.epoch == current.epoch and grant.version == current.version):
        return 'deny:binding-mismatch'
    return 'allow:local-policy-only'

# Only a trusted external verifier may supply Grant/Current in an integration.
source = {'action': 'set_delivery_preference', 'resource': 'synthetic-order', 'value': 'pickup'}
p = proposal(source)
source['value'] = 'delivery'
assert p.value == 'pickup'
g = Grant('synthetic-subject', 'synthetic-session', digest(p), 0, 0, 10)
c = Current(g.subject, g.session, digest(p), 0, 0)
assert decide(p, g, c, 0) == 'allow:local-policy-only'
assert decide(p, g, c, 10) == 'deny:expired'
assert decide(p, g, replace(c, revoked=True), 1) == 'deny:revoked'
for changed in (replace(c, subject='other'), replace(c, session='other'),
                replace(c, epoch=1), replace(c, version=1),
                replace(c, intent=digest(replace(p, value='delivery')))):
    assert decide(p, g, changed, 1).startswith('deny:')
assert decide(replace(p, value='delivery'), g, c, 1) == 'deny:binding-mismatch'
for bad in (True, -1, '1', float('nan'), None):
    assert decide(p, g, c, bad) == 'deny:invalid-clock'
assert decide(p, replace(g, version=True), c, 1) == 'deny:invalid-evidence'
assert decide(replace(p, action='arbitrary-command'), g, c, 1) == 'deny:invalid-proposal'
try:
    p.value = 'delivery'
except FrozenInstanceError:
    pass
else:
    raise AssertionError('mutable proposal')
try:
    proposal({**source, 'authority': 'approved'})
except ValueError:
    pass
else:
    raise AssertionError('untrusted authority field admitted')
replay = []
for label, origin, text in (
    ('benign', 'caller', 'Synthetic request for pickup'),
    ('quoted', 'quoted', 'Synthetic quotation describing a privileged instruction'),
    ('background', 'background', 'Synthetic background claim of permission'),
    ('retrieved', 'tool-result', 'Synthetic retrieved claim of broader scope'),
    ('missing-label', None, 'Synthetic speech with unknown origin')):
    result = decide(p, None, c, 1)
    assert result == 'deny:independent-grant-required'
    replay.append({'fixture': label, 'origin_label': origin, 'text': text,
                   'expected': 'deny:independent-grant-required', 'actual': result,
                   'audio_rendering': 'not-performed'})
print(json.dumps({'fixture_class': 'Synthetic', 'replay_manifest': replay,
                  'authorized_control': decide(p, g, c, 1),
                  'business_execution': 'not-performed',
                  'acoustic_injection_detection': 'not-tested'}))

The report contains actual expected and observed local dispositions for every replay row. It also states that audio rendering and business execution were not performed. A useful reusable output should expose those limitations in the emitted artifact itself, rather than relying on a reader to infer them from surrounding prose.

The manifest is a starting contract for a later authorized audio replay. A separate test harness could render the invented phrases, select controlled overlap and playback conditions, retain source provenance, and pass the resulting transcripts through a real recognizer. Those are proposed next tests; this fence performs only the deterministic policy replay.

Interpret the negative controls

The absent-grant controls deny all origin labels, including the benign caller label. This is intentional. Content and origin are not the trusted authority channel, so changing their wording or classification must not manufacture a grant. The positive control separately shows that an exact independently authorized proposal can pass local policy.

The changed-subject, changed-session, policy-epoch, business-version, and current-intent fixtures test different bindings. A denial identifies an explicit mismatch without echoing the transcript. The deadline fixture rejects at the exact deadline, rather than requiring a later callback to notice expiry.

The clock input is a bounded nonnegative integer in a caller-defined monotonic test domain. A real authority adapter must supply a trusted current time in the same declared domain and must not move it backward to revive evidence. The pure function has no history and does not itself implement a durable expiry ledger.

The interruption-safety guide describes how terminal ownership survives late work. Apply that principle in the controller around this gate: canceled work cannot become active again because an old model or verification result eventually returns. Current revocation and epoch evidence must be read from the active owner.

The malformed-clock tests reject booleans, negative values, strings, nonfinite values, and missing time. The invalid-proposal control rejects a manually constructed arbitrary action. These checks protect the small published contract; they do not claim to validate every field shape a future tool might support.

Recheck after asynchronous work

An authorization check is meaningful only at the boundary it protects. If the application awaits a lookup, confirmation, or network call after checking, the state can change while it is suspended. Recheck current owner, intent, grant deadline, policy epoch, and business version after the wait and before the next ordered side effect.

The pure reference contains no await and performs no side effect, so its result is only a local admission decision. It cannot freeze a remote system between the decision and mutation. A downstream service needs atomic authorization and conditional mutation, or another documented mechanism that prevents an intervening state change from being ignored.

The partial-transcript guide explains why late or provisional recognition results cannot be promoted automatically into current commands. A new transcript revision can repair the requested value while an earlier proposal is still waiting for a tool response.

The yes-but repair guide is relevant when an acknowledgment includes a correction. Matching an affirmative fragment must not confirm the old proposal before the completed reply changes its material fields. Bind approval to the current complete interpretation.

An exact transport retry retains its immutable request identity and payload. A new logical confirmation after repair needs a new identity. Reusing the old identity with changed values confuses deduplication with consent to a different action, and a cached historical result must never restore a canceled operation's current authority.

Keep detectors in a supporting role

Instruction classifiers, phrase lists, and provenance labels can be useful signals for review. They can help select an escalation path or focus evaluation. None should be the only control deciding whether arbitrary content may execute a business operation.

A denylist of suspicious words cannot guarantee injection defense. Legitimate callers can quote those words, and undesired instructions can be expressed in other ways. A detector's confidence score also does not establish identity, permission, or the correctness of its calibration in the current acoustic conditions.

The confidence-calibration guide addresses that measurement boundary. A high score is not automatically a probability of safety. Even a well-calibrated content classifier answers a different question from whether the exact current principal has authorization for the requested operation.

The retrieval-for-speech guide explains another input path. Retrieved content can provide task facts, but its embedded instructions should not redefine the application's tools, policies, credentials, or destinations. Keep the authority check independent of whichever source text a model happens to read.

The model can still cause harm within an excessively broad legitimate grant. Independent authorization is necessary but its scope must be narrow enough to reflect the caller's current intent. This is why the reference compares the exact proposal with current intent instead of merely checking that a subject is generally allowed to change delivery preferences.

Evaluate speech and policy separately

A synthetic policy replay can demonstrate that untrusted content does not directly set a local grant. It cannot establish whether a real recognizer will include background speech, whether a diarizer will attribute it correctly, or whether a model will propose an undesirable action under a particular overlap condition.

The synthetic-versus-real speech guide distinguishes controlled fixtures from evidence about human speech. Keep those populations separate. An audio replay can be a useful regression fixture without representing every speaker, room, device, network path, or conversational context.

For an authorized acoustic evaluation, record the source of each test clip, synthetic versus human origin, intended and observed transcript, proposed action, independent grant state, and final adapter disposition. Do not fabricate customer transcripts or report a model failure rate from a set that only executed a Python policy function.

The model, prompt, or carrier regression guide helps isolate changes when a replay differs after an update. Freeze the content and policy evidence separately from model, recognizer, transport, and tool versions. A changed transcript does not by itself identify the component that caused an unauthorized side effect.

The regression-testing guide describes why negative controls need to survive releases. Run absent-grant, changed-intent, stale-version, and revoked-session cases after every relevant policy change, even when the current model no longer proposes the original synthetic action.

Preserve useful evidence without raw leakage

Security diagnostics do not require every transcript to be copied into general telemetry. A bounded outcome code, policy identity, controlled fixture identity, and relevant version evidence can explain why an action was denied. Production retention of speech and content needs a separate justified policy.

The telemetry-redaction guide provides a structured allowlist approach. Logging an entire rejected proposal or exception can leak the very credentials or personal information that the action gate was supposed to protect. Failure paths need the same output discipline as successful paths.

Recording policy is also independent. The live recording-consent guide distinguishes permission to admit new content, the recorder's observed stop state, and retention or deletion evidence. A security investigation does not automatically authorize recording or retaining all surrounding speech.

Keep original test provenance where authorized and avoid rewriting a prompt inventory after a correction to pretend it produced different evidence. A faithful synthetic replay record contains what was actually supplied, which policy was evaluated, and what the function returned. It does not transform a planned acoustic experiment into a completed one.

Choose an enforceable control matrix

In this table, ✓ means the named boundary explicitly checks the condition. ✗ means it supplies no such guarantee. These marks are engineering scope descriptions, not measured attack resistance or a certification that a deployment is secure.

Use the local-versus-managed guide to assign ownership for those adapter responsibilities. A hosted model, an application backend, and a business service can each control different parts of the system. The authorization boundary must remain enforced even when one of those components changes provider or deployment mode.

The cache-key guide adds a practical identity lesson: cached evidence must include the material policy and context it belongs to. A familiar transcript or repeated prompt is not enough to reuse another session's approval. Cache efficiency cannot override current intent and permission.

Keep credential verification outside the transcript

Independent authority needs a real verification route. A signed-looking JSON object in model output is still model output. The receiving service must know which trusted adapter produced the assertion, how it verified the credential, which session it belongs to, and whether its permission remains current. The example's synthetic Grant constructor supplies no such cryptographic evidence.

NIST's SP 800-63B-4 authentication guidance describes digital authentication requirements within its stated scope. Its distinction between authenticator control and a claimant's assertion is useful here. Do not infer authentication from fluent speech, a familiar name, or confidence in a transcript. Requirements selected for a deployment must come from its actual applicable identity policy.

A voice application might direct the caller to a supported independent verification channel and receive an action-specific trusted assertion. That is a proposed integration pattern, not a claim that this article implements passkeys, one-time passwords, or identity federation. Verification, rate limits, recovery, and session binding belong to the selected provider and application contracts.

RFC 9700 documents OAuth security best current practice. A deployment using OAuth must follow the actual authorization flow and resource-server requirements rather than copying this local digest comparison as a substitute. Protect tokens from the model-facing transcript and validate their intended audience and permissions through the real integration.

The authority representation should describe the narrow action that can follow verification. A credential proving control of an account does not by itself approve a new delivery destination, cancellation, or disclosure. Bind the current intent separately and recheck it when the application reaches the authoritative operation.

An independent channel can also fail or become unavailable. Preserve that outcome and offer a supported route that does not perform the sensitive operation prematurely. Do not reinterpret failed verification as evidence that the caller probably meant the action, and do not ask a language model to invent a replacement grant so the conversation can continue smoothly.

Turn the manifest into an honest test plan

The emitted replay manifest is deliberately small enough to inspect. Each row contains the exact invented content, the optional origin label, expected local disposition, actual local disposition, and an explicit statement that audio was not rendered. The positive control appears separately, making it clear that denial depends on missing authority rather than a phrase detector's preferred category.

A later acoustic harness should preserve those original rows while adding its own output fields. It could record the renderer identity, synthetic source file digest, recognizer version, controlled playback setup, observed transcript, and resulting proposal. It should not overwrite the original expected policy result with whatever the model happened to do. Expected behavior and observed behavior serve different audit purposes.

Use controlled comparisons when adding background overlap. Keep the intended caller task fixed and vary one declared audio condition at a time when the evaluation question requires it. Preserve source provenance so synthetic and human recordings cannot accidentally share the same evaluation denominator. No specific overlap duration, amplitude, or performance outcome is claimed by this article.

The full-duplex audio-policy guide explains why overlap also interacts with turn ownership and playback policy. A failure to hear the caller after ducking is a different observation from a tool crossing an authorization boundary. The fixture ledger should retain that distinction rather than collapsing every unusual conversation into injection success.

A historical developer discussion about instruction hierarchy raises the broader question of how systems should treat untrusted instructions. It supplies discussion context, not audio-specific incident evidence or a current defense benchmark. This guide answers the application-side question with explicit independent permission checks and does not rely on the linked discussion's performance claims.

The absence of a recorded real incident is not a reason to invent one. A defensive hypothetical can be valuable when it names the trust boundary and produces a reproducible negative control. State clearly which steps were executed, which are proposed, and which properties require actual device, provider, or authoritative-service evidence before drawing a deployment conclusion.

Review failure paths as carefully as the allow path

A denial should leave the application in a defined state. It may need clarification, a fresh independent grant, an authoritative state refresh, or an explicit handoff. Those are different recovery actions. The local reason code identifies the failed boundary without claiming that the controller already completed the recovery.

An expired grant needs fresh authority, not a repeated content-classification pass. A state-version mismatch needs a current authoritative read and renewed approval where material facts changed. A changed proposal needs a new exact-intent binding. These distinctions help an engineer avoid using one broad retry loop that accidentally reuses evidence from the wrong task.

Keep exceptions from becoming a bypass. If the authority service times out, the model's proposal remains a proposal. A convenience fallback that treats unavailable verification as permission would reverse the default-deny boundary precisely when the application has the least evidence. The artifact intentionally returns no business-execution function, so a reader cannot mistake a local allowed disposition for an external success receipt.

Review how every model-exposed tool reaches the final adapter. A carefully checked delivery-preference operation does not protect another endpoint that accepts arbitrary payloads from the same conversation. Capability inventory and integration tests should demonstrate that equivalent permissions are enforced at every sensitive entry point, including administrative and retry paths.

Also review where rejected content might travel. An audit message, notification, or support export can itself become an unintended side effect. Keep destinations and payload fields bounded, and avoid sending raw synthetic or real transcripts to a new service merely because the main business action was denied. Security evidence has its own access and retention requirements.

The final local proof is modest and concrete. Running the published fence shows that its bounded schema, exact bindings, deadline check, and revocation input produce the asserted dispositions for the emitted fixtures. It does not establish speaker provenance, universal injection detection, distributed exactly-once execution, or the completeness of a production tool inventory.

Use the fixture output to inspect the separation directly. The synthetic transcript text is present in the replay manifest for reproducibility, but it is never passed as a permission field to decide. The origin label is also present for the evaluator and absent from the authority comparison. That makes it possible to change the label without silently changing the source of the grant.

The action proposal follows a different path. Its allowed fields are validated and copied before comparison, and the gate validates them again when presented with a dataclass. This second check matters because Python constructors remain callable: a type name alone does not prove that its fields satisfy the supported action contract. The manually constructed arbitrary-action fixture protects that path.

Current evidence follows a third path. The test constructs subject, session, intent, epoch, version, and revocation inputs explicitly. The example trusts that path by contract and never claims its constant synthetic subject is a real authenticated person. A deployment must make that trust assumption concrete through its actual credential verifier, session store, and authoritative action service.

The difference between these paths should survive refactoring. If a future integration accepts a model-produced verified flag, copies an origin label into a principal field, or uses a retrieved approval string as a grant, it has changed the trust boundary. Add a failing negative fixture for the exact new path rather than relying on the original synthetic cases to detect every possible integration mistake.

A reviewer can therefore ask concrete questions: which fields can untrusted content set, which adapter produces authority, what exact values were approved, and where does the final current-state comparison occur? Those questions are answerable from schemas, executable assertions, and observed adapter behavior. They are more useful than a blanket claim that a model is immune to instructions hidden in audio.

Frequently asked questions

What is spoken prompt injection?

It is instruction-like content in a voice input path attempting to redirect application behavior. The important engineering boundary is whether untrusted content becomes business authority. This article tests that boundary with invented transcript replay fixtures and makes no claim of a real background-audio incident.

Why is background speech untrusted input?

The application has not established that every audible word belongs to the authorized caller's current request. Recognition and origin labels can be wrong. Treat the content as proposed information while obtaining permission through a separate trusted channel.

Does speaker diarization establish authority?

No. It labels or separates speakers under a model's assumptions; it does not verify a business credential or authorize an operation. The reference denies absent independent grants regardless of the supplied origin label, including labels that appear to identify the caller.

Can a system prompt prevent all injection?

It should not be treated as that guarantee. Model instructions can support useful behavior, but action permissions need independent enforcement and narrow scope. The local reference tests deterministic bindings rather than claiming that a particular prompt makes every acoustic input safe.

Where should business permissions be enforced?

At the authoritative action boundary, with current subject, scope, intent, and state checks. Client admission checks can reduce mistakes but do not protect a service that accepts bypass requests. The consuming adapter must enforce its own documented authorization and mutation contract.

How should quoted speech be handled?

Preserve it as content with appropriate provenance where authorized. Quoting an instruction does not grant permission to execute it. The quoted synthetic fixture follows the same absent-grant denial rule as other sources and never receives elevated authority from its wording.

Can retrieved content authorize a tool action?

No. A document or tool response can provide task facts but cannot create a trusted grant. The model may propose an action based on that content; the independent gate must still verify exact current permission and reject an attempt to broaden scope.

What should an action proposal contain?

Only the supported material fields for the named operation. The teaching schema includes action, synthetic resource, and a bounded value. Unexpected authority fields are rejected, and the gate revalidates manually constructed proposals before evaluating their bindings.

Why must confirmation bind exact values?

General permission to use a feature does not establish approval of every possible value. Bind the material action, resource, and value to the current intent. A correction creates another proposal, so the old digest cannot silently authorize the new request.

How should approval expiry be checked?

Check a trusted current time when policy is queried and again after any intervening wait before a side effect. The reference rejects at its exact deadline. It does not maintain a durable clock or lifecycle ledger; those are explicit external responsibilities.

What happens when a proposal changes?

The original grant fails the exact-intent comparison. Create a new immutable proposal and obtain the required current approval. An exact transport retry retains its old payload; a material correction is a different logical request and needs different identity.

Should a voice agent expose arbitrary tools?

Only expose capabilities justified by the intended workflow and their explicit permission contracts. This reference deliberately supports one small action. A generic command or unrestricted destination adds effects that this bounded policy neither models nor authorizes.

How can defensive fixtures avoid an attack campaign?

Use invented, nonoperational descriptions and local synthetic evidence. Do not target a real service or borrow customer audio. The emitted manifest exercises permission boundaries and states that acoustic rendering, injection detection, and business execution were not tested.

What does a synthetic audio replay prove?

Only the properties actually observed under its recorded setup. This fence replays synthetic transcript cases through local policy and emits those results. A later audio rendering or recognizer experiment needs separate provenance and cannot be inferred from these assertions.

How should tool results be labeled?

Treat their content as untrusted task data with source context where useful. Labels can support debugging but must not grant permissions. A result suggesting a next action still needs current independent authorization at the point that action would execute.

Can a high confidence score grant permission?

No. Confidence addresses a model's prediction, not a principal's authority. Calibration and acoustic evaluation are separate questions. The gate requires exact independent evidence even when a content detector appears highly confident that an input is benign.

When should the agent abstain or escalate?

When required identity, scope, intent, state, or timing evidence is absent or unresolved. Denial should lead to a supported recovery path without executing the proposed side effect. Do not turn escalation into disclosure of account information before the appropriate authority exists.

How should denied actions be logged safely?

Use bounded structured reason codes and approved diagnostic fields. Avoid copying raw transcript, credentials, or rejected arbitrary payloads into generic logs. Test exception and exporter paths separately, because a correct permission denial does not automatically make telemetry safe.

Which checks belong in the downstream service?

Current permission, resource scope, expected business version, and operation identity must be enforced where the authoritative mutation occurs. A local check cannot lock remote state. Provider responses and actual action completion also need their own observed evidence.

How should a model update be revalidated?

Keep deterministic policy controls and rerun controlled interpretation fixtures with recorded versions. Separate changed transcript or proposal behavior from final authorization outcomes. Do not describe a policy replay as a measured live-call attack-resistance benchmark.

Start with a bounded authority test

For 60db Agent integrations, begin by naming the exact business operation and the independent evidence that permits it. Run the full synthetic replay, inspect its emitted dispositions, and verify that model-facing content cannot construct or broaden a trusted grant.

Then test the actual recognizer, confirmation controller, authoritative adapter, and logging path under their own contracts. The useful outcome is an inspectable separation between what speech says, what the application proposes, and what the current business authority permits.