TIDEMARK

Selection, not supply: a deterministic runtime boundary that prevents AI agents from supplying protected values to side-effecting tools.

Comment

Inspiration

Autonomous agents increasingly act through tools that can create real side effects: payments, messages, infrastructure changes, database writes, and other privileged operations.

The problem is that model-generated tool arguments are still untrusted input.

TIDEMARK explores a narrower security boundary:

Selection, not supply.

A model may select an opaque reference to something the runtime already trusts. It may not directly supply a protected value to a side-effecting tool.

What it does

TIDEMARK places a deterministic authorization boundary between model-authored tool arguments and execution.

For protected arguments, the agent proposes an opaque reference. The trusted runtime resolves that reference, binds the protected value, evaluates the complete call against an immutable policy snapshot, and only then may create a sealed single-use prepared call.

Execution performs another validation before adapter entry.

This separates several facts that agent systems often collapse together:

proposal ≠ authorization ≠ execution ≠ observed effect

The integrated Security Decision Trace makes those boundaries visible.

The demo includes six deterministic scenarios, including:

  • benign selection → trusted binding → ALLOW;
  • raw protected-value supply → DENY with zero observed side effects;
  • forged or misbound references;
  • bound-exceeded denial;
  • replay rejection with no second local effect;
  • model non-attempt.

How we built it

TIDEMARK is implemented as a framework-neutral Python runtime with:

  • deterministic policy evaluation;
  • trusted reference resolution;
  • immutable policy snapshots;
  • sealed single-use prepared calls;
  • execution-time revalidation;
  • append-only evidence and reconciliation;
  • masked, allowlisted publication projections;
  • a read-only Security Decision Trace UI;
  • a Google ADK callback adapter;
  • a synthetic payment vertical slice.

The current integrated demo is deterministic and offline so judges can reproduce the security semantics without credentials or cloud access.

Separately, we captured historical live-model evidence using Gemini 3.6 Flash through Google ADK and the Gemini Developer API, and historical deployment evidence from a bounded provider-free Google Cloud Run Job. These are explicitly separated from the current offline demo rather than presented as active infrastructure.

TIDEMARK was built during the hackathon. Third-party libraries and SDKs used by the project are identified in the public repository and its dependency manifests; no pre-existing proprietary application code was incorporated into the submission.

Challenges we ran into

The hardest part was preserving authority boundaries across the entire lifecycle rather than merely deciding whether a tool call looked safe.

An ALLOW decision cannot itself be treated as execution authority. Prepared authority has to be bound to the exact call, correlations, policy state, adapter target, and single-use execution state. Evidence also has to be durable before effects occur without leaking the protected values it is supposed to protect.

Reproducibility introduced another challenge: SDK behavior can drift even when declared dependency ranges remain valid. The final release therefore pins the Google GenAI SDK version used by the validated integration contract.

Accomplishments that we're proud of

The final release passes:

  • 1,107 / 1,107 full regression tests
  • 111 / 111 focused verification tests
  • a 35-scenario adversarial security matrix
  • deterministic six-scenario offline reproduction

The evidence model distinguishes policy decision, prepared authority, execution, replay, and observed effects instead of inferring one from another.

Most importantly, the negative cases are measurable: a denied protected-value supply produces no prepared call, no execution start, and no synthetic payment; replay produces no second local effect.

What we learned

Agent security is not only about controlling what a model can say or choose.

Once agents have tools, security becomes a systems problem involving authority provenance, deterministic policy, execution-time validation, single-use capabilities, and evidence that can distinguish attempted actions from actual effects.

We also learned that demonstrability matters. A security property that cannot be independently reproduced and inspected is much harder to trust.

What's next for TIDEMARK

TIDEMARK is currently a bounded security mechanism and evidence product, not a production-ready general authorization platform.

Future work could explore distributed execution semantics, broader tool adapters, stronger external attestation, richer policy composition, and additional protected-resource domains while preserving the same core rule:

the model selects; the trusted runtime resolves and binds.

Built With

Share this project:

Updates

Submission history