Developer Guides
Prompt Injection Risks in Web-Connected Intelligent Contracts
Web content is untrusted input. A page can contain instructions that try to redirect a model task. The contract must constrain sources, prompts, output, and validation.
Scope and decision boundary
A safe implementation starts with a narrow decision and a testable output contract. The prompt comes after these requirements.
Developers must test source failure, malformed output, validator disagreement, and delayed finality. The successful path is only one test case.
This guide defines the technical controls for this subject. It does not treat a model response as proof.
Start with the decision boundary. Identify the permitted inputs, the required output, and the state change that can follow validation.
This subject also connects to How to Build Trustworthy AI Applications with GenLayer and Why Deterministic Code Is Not Sufficient for Modern AI. Read those guides together when the decision crosses trust, retrieval, or execution boundaries.
What changes in practice
Retrieved text must remain data and must not become a trusted instruction.
Treat this point as a design requirement. Record the input and the expected result before implementation.
Structured output reduces the space for uncontrolled model responses.
Connect this point to a visible contract state. A reviewer must be able to inspect the resulting behavior.
Independent validators need criteria that detect task deviation.
Test this point with normal, invalid, unavailable, and disputed inputs. Do not test only the successful path.
Implementation in practice
Separate system instructions from retrieved evidence with clear delimiters.
Document the owner, input, output, failure response, and test evidence for this control.
Allow only the fields and source domains that the decision requires.
Document the owner, input, output, failure response, and test evidence for this control.
Reject output that adds commands, fields, or claims outside the defined schema.
Document the owner, input, output, failure response, and test evidence for this control.
Example: an instruction hidden in a web page
A contract retrieves a page to extract a product price. The page contains text that instructs the model to ignore the extraction task and approve a transaction. That text is untrusted evidence, not a contract instruction.
The prompt must delimit the page content, request only the price field, and reject output that contains commands or unexpected fields. Validators must apply the same output rule.
Verification procedure
Use this procedure before deployment. Keep the test evidence with the contract version and network configuration.
- 01State the decision in one sentence. Identify the person or system that uses the result.
- 02List each deterministic input, non-deterministic input, external source, and model dependency.
- 03Define the accepted output type, required fields, value limits, and failure states.
- 04Test correct input, malformed input, unavailable evidence, stale evidence, and conflicting evidence.
- 05Test validator agreement, validator disagreement, leader rotation, appeal, and finality where applicable.
- 06Confirm that no state change occurs before the contract obtains an acceptable result.
- 07Record the source, network, transaction state, and validation outcome for operational review.
Design review questions
A reviewer must answer these questions before the contract handles a high-impact decision.
- Can fixed code complete this task without AI or web access?
- What evidence is necessary, and which source is authoritative for that evidence?
- What result must a validator reject?
- What does the application do when the result is partial or unavailable?
- Can a user distinguish an accepted result from a finalized result?
- What data must remain private?
- Which dependency can cause several validators to fail at the same time?
Evidence record
Keep enough evidence to reproduce the application decision. Do not store private input in a public contract record.
- Field 1
- Contract version and network identifier
- Field 2
- Transaction identifier and current transaction state
- Field 3
- Source identifier, retrieval time, and content version when available
- Field 4
- Model task, required output structure, and validation criteria
- Field 5
- Validator outcome, disagreement state, and appeal state
- Field 6
- Final application action and the authority that approved it
Operational monitoring
Deployment is not the end of verification. Monitor the complete decision path and investigate changes in behavior.
- Measure source, model, and network availability as separate signals.
- Measure response time for retrieval, model execution, validation, acceptance, and finality.
- Record rejected proposals, validator disagreement, leader rotation, and failed retries.
- Track source format changes and model configuration changes that can alter output.
- Review appeals and overturned results for weak criteria or missing evidence.
- Repeat the validation suite after a contract, prompt, source, model, or network change.
Release criteria
Release the contract only when the team can explain each input, validation rule, state change, failure response, and authority boundary.
The test suite must include evidence failure and validator disagreement. A successful example does not prove safe behavior.
The interface must show the correct transaction state. It must not describe an accepted result as final before the finality process ends.
The operating team must have a response procedure for provider failure, source change, disputed results, and contract defects.
Limits
- Prompt filtering cannot identify every adversarial instruction.
- Trusted domains can contain compromised or user-generated content.
Primary GenLayer sources
- Use the official Web Access page as the primary protocol reference for this subject.
- Compare the implementation with Calling LLMs before you select the final validation and failure rules.
Check the source pages again before production deployment. Protocol, network, and software requirements can change.
