Security and Trust Boundaries
TeaQL provides structural controls around generated queries, mutation audit intent, runtime context, provider execution, and optional tools. These controls reduce particular classes of mistakes; they do not make generated applications secure without application policy and infrastructure controls.
Boundary Map
| Boundary | TeaQL mechanism | What it helps enforce | What remains outside the mechanism |
|---|---|---|---|
| Model → generator | KSML evaluation and generated typed APIs | Model validation and repeatable API shape. | Trust in the generation service, model review, source provenance, and generated diff review. |
| Generated code → application code | Generated Q, request, entity, checker, and metadata APIs | Keeps ordinary data access on inspected typed methods. | Handwritten SQL, reflection/unsafe paths, generated-file tampering, and business-rule correctness. |
| Query → execution | comment → purpose → executable request | Requires declared read intent on maintained generated paths. | Whether the purpose is truthful and whether the actor may read the data. |
| Entity change → persistence | auditAs/audit_as → save | Requires an audit description on maintained generated mutation paths. | Authentication, authorization, approval, transaction design, and audit sink durability. |
| Request → runtime policy | Java UserContext/RequestPolicy; Rust runtime context and generated provider traits | Central place to apply actor, tenant, route, and policy decisions. | Correct policy registration, complete coverage, identity verification, and bypass testing. |
| Runtime → provider/database | Data-service executor/provider contracts | Structured query/mutation execution and provider-specific binding. | Database accounts, row-level security, encryption, backups, migrations, availability, and handwritten provider code. |
| Application → external tool | Java ToolProvider/ToolPolicy/acknowledgement; released Rust capability contracts when present | Capability discovery, risk policy, deployment acknowledgement, and intent phase where implemented. | Network/filesystem sandboxing, destination allowlists, credentials, payload validation, and unregistered handwritten I/O. |
| Runtime → audit/log sink | Audit metadata, masking configuration, log levels, sinks | Produces reviewable execution/change records and can mask declared fields. | Tamper resistance, transport security, access control, retention, deletion, alerting, and completeness across custom paths. |
| Build → deployment | Pinned clients/runtime versions and reproducible checks | Makes the tested generator/runtime combination visible. | Dependency provenance, artifact signing, image scanning, host hardening, patching, and incident response. |
Mechanisms and Limits
SQL Injection
Generated query APIs represent ordinary filters and values structurally, so provider implementations can bind values instead of concatenating application strings. Any raw SQL escape hatch, provider implementation, migration script, or handwritten JDBC/database call still requires parameterization and review.
Object and Tenant Authorization
UserContext, request policy, generated filters, and provider routing give the
application a central enforcement point. They do not infer ownership or tenant
rules from the model. Test list, single-record, aggregation, association,
mutation, export, and administrative paths for the same policy coverage.
Mass Assignment and Mutation Scope
Generated update methods make changed fields visible and audit wrappers make the declared action visible. Inbound payload binding, writable-field policy, state-transition rules, approval workflows, and privileged fields remain application responsibilities.
Query Cost and Availability
Generated pagination, selection, and association APIs help make query shape reviewable. Production limits, timeouts, rate limits, concurrency, pool sizing, relationship depth, aggregation cost, and denial-of-service controls must be configured and load-tested by the application team.
Sensitive Data and Audit
_audit_mask_fields and runtime log configuration can reduce sensitive values
in audit output. Masking is not authorization, encryption, deletion, or data
minimization. Review every sink, custom log statement, error response, trace,
export, backup, and analytics path.
Agent and Tool Capabilities
Java 1.525-RELEASE verifies provider discovery, risk-based ToolPolicy,
optional acknowledgement, and HTTP intent phases. Rust's verified
teaql-tool-core 1.0.0 supplies audit configuration and a generic purpose
wrapper, not a complete executable capability sandbox. Arbitrary handwritten
Java or Rust code remains governed by dependencies, runtime permissions, and
the operating system.
See the Java Agent Tool Boundary and Rust Agent Tool Boundary for the version-specific evidence.
Production Review Checklist
- Pin and record generator, client, runtime, provider, framework, and database versions.
- Review the model and generated diff; never fix a security mismatch by editing generated files.
- Verify identity creation and propagation before request policy runs.
- Test tenant and object authorization for every execution shape.
- Require concrete query purpose and mutation audit descriptions.
- Restrict raw SQL and direct provider/database access.
- Allow only required external tools, destinations, methods, and credentials.
- Protect and monitor audit/log sinks; test masking and retention.
- Use least-privilege database and deployment identities.
- Scan dependencies/images and define patch, rollback, backup, and incident procedures.
- Preserve build and runtime evidence for the released combination.
Security Claim Rule
Describe a TeaQL mechanism as a control only for the generated/runtime path that was inspected and tested. Do not claim complete prevention of SQL injection, authorization bypass, data leakage, audit tampering, or agent misuse without system-level evidence covering handwritten code and infrastructure.
Related guidance: