DEV Community: Arpan Patra

Building a user-isolated Gemini journal on Cloud Run

Arpan Patra — Sun, 06 Sep 2026 16:41:56 +0000

I spent a day building Waypoint for the Google Gen AI APAC Ideathon. The brief was a "Personal Gemini Journal": Firebase Auth, multi-turn Gemini, per-user Firestore isolation, and API keys in Secret Manager. This is what I built on top of that, and the things that nearly went wrong.

Live: https://waypoint-796599668154.us-central1.run.app
Code: https://github.com/imarpanpatra/waypoint

What it does

You write about your day. Gemini talks it through with you as a real conversation. When you close a session it is distilled into its bearing, one sentence naming the thread underneath the surface topics, plus a mood and energy score, themes, and the unfinished items you mentioned.

Every closed session is embedded, so you can later ask "what was I stuck on in August?" and get an answer cited to dated entries. Each session also produces publication drafts: a LinkedIn post, an X thread, a blog outline and a video idea, grounded strictly in what you actually wrote.

The isolation decision

The requirement was "zero cross-user leakage". The usual approach is a global collection with a userId field and a .where() clause on every query. That works right up until someone forgets one.

Instead every document lives under the owner's subtree, and the uid is only ever read from the verified token:

export function userRoot(uid) {
  if (typeof uid !== 'string' || !uid) {
    throw new Error('userRoot() requires a verified uid.');
  }
  return firestore().collection('users').doc(uid);
}

No route accepts a user id from a request body, query string or header. There is no code path that can be pointed at another account, because the reference is constructed from the decoded token at the point of use.

That matters most for semantic search. A shared vector index is where cross-tenant leaks usually show up in RAG systems. Here the candidate set is read from users/{uid}/sessions, so isolation is structural rather than filtered.

Server-authoritative writes

The starter rules in the codelab suggest:

allow read, write: if request.auth != null && request.auth.uid == userId;

That is correctly isolated, but it lets a client write directly to the database, which means server-side validation, sanitisation and embedding generation can all be skipped by anyone willing to open a console. My rules deny client writes entirely:

match /users/{userId} {
  allow read: if isOwner(userId);
  allow write: if false;

  match /private/{docId} {
    allow read, write: if false;
  }
}

The private/ subcollection holds the Discord webhook URL, readable by nobody on the client, not even the owner. The API returns only a masked form.

Proving it instead of claiming it

Documentation that says a system is isolated is worth very little. So the app has a /security page that runs six probes in your browser against the live deployment:

Read your own profile document. Should succeed.
Read a document under a different uid. Should be permission-denied.
Write directly to your own tree from the browser. Should be permission-denied.
Call the API with no bearer token. Should be HTTP 401.
Submit the cloud metadata address as a Discord webhook. Should be HTTP 400.
Download the page's own JavaScript and scan it for Google API key literals.

Five of the six are supposed to fail. That is the point.

SSRF, the feature that needed the most care

Waypoint can push a weekly digest to a Discord webhook you own. A user-supplied URL that the server then fetches is a textbook SSRF primitive. On Cloud Run, pointing it at 169.254.169.254 would hand over the runtime service account token.

The control is a hostname allow-list, not a deny-list, because DNS rebinding and redirects defeat deny-lists:

const ALLOWED_HOSTS = new Set([
  'discord.com', 'discordapp.com', 'ptb.discord.com', 'canary.discord.com',
]);
const WEBHOOK_PATH =
  /^\/api\/(?:v\d+\/)?webhooks\/\d{5,25}\/[A-Za-z0-9_-]{20,120}$/;

Plus https only, no embedded credentials, redirect: 'error' so an allowed host cannot bounce the request somewhere internal, and an 8 second timeout so a hung third party cannot pin an instance open.

There are eleven test cases for this, including the metadata server over https with a valid webhook path, which is the one that isolates the host check from the scheme check.

Three things that nearly went wrong

The free tier is regional

I nearly deployed to asia-south1 because it is closer to home. Cloud Run's Always Free allowance only applies in us-central1, us-east1 and us-west1. Worse, the same value sets the Firestore location, which is permanent once the database is created. Getting that wrong means tearing the project down and starting again.

A caught error still killed the process

The optional Maps secret lookup failed cleanly, logged a tidy warning, and then the service died a tick later.

Secret Manager's client builds its gRPC stub lazily and holds the promise internally. When credentials cannot be resolved, that internal promise rejects with nobody awaiting it, and under Node 22 an unhandled rejection terminates the process. Catching the error from accessSecretVersion is not enough:

const client = getClient();
await client.initialize();   // forces stub creation inside this try block
const [version] = await client.accessSecretVersion({ name: resource });

I confirmed this was the real fix rather than a coincidence by removing the process-level safety net and checking the service still stayed up.

Cloud Run gives you two URLs

A new-style service-projectnumber.region.run.app and a legacy service-hash-uc.a.run.app. Both route to the same service, and Firebase Auth will refuse sign-in on whichever one you did not add to authorised domains.

Verifying the security controls actually work

There are 31 tests covering the pure functions where a regression would be silent: the SSRF allow-list, the prompt-injection fence a user must not be able to escape, the sanitiser that strips zero-width and bidi characters, and undefined-stripping before Firestore writes.

I confirmed they catch regressions by deliberately breaking things. Disabling the SSRF host allow-list turns four tests red. Injecting a dangerouslySetInnerHTML and a fake API key is caught by the pre-deploy scanner. A test that has never failed has not been shown to work.

Prompt injection

Journal text is untrusted input. It gets wrapped in a delimiter the user cannot forge, and every system instruction states that content inside it is data, never instructions:

export function asUntrustedData(text) {
  const escaped = String(text)
    .split(FENCE_OPEN).join('[fence]')
    .split(FENCE_CLOSE).join('[/fence]');
  return `${FENCE_OPEN}\n${escaped}\n${FENCE_CLOSE}`;
}

Stripping the delimiters from user text first is what stops someone closing the fence early and escaping into instruction context.

This is mitigation, not a solution. The blast radius is deliberately small: the model has no tools, no function calling and no database write access, so a successful injection affects the text of one reply and cannot reach data.

Model resilience

No call site names a model. Everything routes through a fallback ladder that retries on recoverable upstream statuses, so one unavailable model cannot take the application down:

const DEFAULT_LADDER = [
  'gemini-3.6-flash',
  'gemini-3.1-flash-lite',
  'gemini-flash-latest',
  'gemini-3.7-flash',
];

const RECOVERABLE = new Set([429, 500, 503, 404]);

The ladder is overridable with an environment variable, so a model rename is a gcloud run services update rather than a rebuild and redeploy.

Worth stealing

Two ideas I would use again on anything multi-tenant.

Make isolation structural, not conditional. If the only way to address data is a helper that takes a verified uid and builds the path from it, there is no query left to forget a filter on.

Ship a page that tries to break your own app. The security page took an hour and it is the thing I would show first. It converts a claim into something a reviewer can check in ten seconds from their own browser.

The full source, the threat model, and the deployment steps are all in the repo: https://github.com/imarpanpatra/waypoint

#AccelerateAIwithCloudRun

Building an AI Agent That Can Actually Take Action

Arpan Patra — Sun, 30 Aug 2026 17:56:16 +0000

Adding a dependency is the least careful thing most of us do all week.

You run npm install some-utils, and you've just agreed to run a stranger's code on your laptop, in your CI, and eventually in production. The registry ships thousands of new versions an hour. Typosquats, hijacked maintainer accounts, postinstall hooks that phone home, code that ships in the tarball but never existed in the GitHub repo anybody actually reviewed, they all come through that door.

And nobody reads the tarball. I certainly don't.

So for the Agent Harness Hackathon I built Portcullis - an agent that reads it for you, and can't add the dependency without asking first.

Repo: https://github.com/imarpanpatra/portcullis

Three-minute walkthrough, if you'd rather watch than read:

The job

You ask it: can I add left-pad to this repo?

It checks whether the name is the attack before it reads any code. Then it pulls registry signals age, publish cadence, maintainers, downloads, known advisories. Then it downloads the actual published tarball into a sandbox, unpacks it, and reads what ships: install hooks, obfuscated payloads, child_process usage, and a diff against the project's own GitHub source at that tag.

Then it gives you a verdict with evidence. And if you want it added, it stops and asks, because that means a branch, a commit and a pull request on a real repository.

That last part is the whole point. Everything before it is research; that step is a write you can't take back.

How it's wired

Three pieces, and TrueForge handles everything between them.

A custom MCP server I wrote for npm intelligence. Four read-only tools over public keyless APIs: registry metadata, download stats, OSV advisories, and typosquat detection.

That last one taught me something. The obvious approach is to search the registry for the package name and look at the neighbours. It doesn't work. Ask npm's search API for expres and express is nowhere in the twenty-five results. The victim is missing from the exact query designed to find it.

So instead of hoping search finds it, I generate the names an attacker would plausibly have registered deletions, adjacent transpositions, doubled letters, homoglyphs like rn→m and probe for them directly. The downloads API takes 128 names per request and returns null for ones that don't exist, so a few hundred candidates resolve in two HTTP calls.

Pointed at expres, it finds express and rather than writing me a security report about a package I never meant to install, it stops and asks:

A git-backed skill holding the audit procedure and a Python inspector. TrueForge clones it into the sandbox on demand. The inspector is standard library only which felt right for a tool whose entire subject is install steps.

The GitHub connector does the write, and it's gated.

The whole agent is one JSON document a model, instructions, those connectors, the skill, and the config:

What TrueForge actually did for me

I wrote about 3,000 lines. None of it was the agent loop.

The harness gave me tool routing over MCP, a sandbox provisioned only when the agent needs one, the approval gate, subagents, sessions that survive the client going away, and Generative UI so the report renders as real components instead of a wall of markdown.

Ask it about five packages and it fans out one subagent each, running at once, results merged into one ranked answer:

Two of those are worth calling out.

Sandbox-as-tool. The agent loop and all credentials stay in the harness; the sandbox only executes. So the thing unpacking a stranger's tarball never sees my GitHub token. For this project specifically that's not a nice-to-have it's the reason the project is safe to run at all.

The approval gate is enforced by the harness, not by my client being polite. A gated call ends the turn. Resuming requires sending an approval event. So a client that ignores the pause doesn't get a pull request faster it gets no pull request. I couldn't have accidentally written past it if I'd tried.

I deliberately didn't add a --yes flag. A flag that pre-approves every write defeats the only claim the project makes, and it'd be the first thing anyone reached for in CI, which is exactly where nobody's watching.

Approve it, and you get the branch, the commit, and the pull request with the exact dependency line it added:

What broke

This is the useful part.

The sandbox had no bash

First real run, the agent gave me a confident, well-structured verdict on express. Registry signals, advisories, the lot.

It had never opened the package.

Every sandbox exec was coming back fork/exec /usr/bin/bash: no such file or directory. The agent tried three shell variations, gave up, and answered from registry metadata alone sounding exactly as certain as it would have if it had done the work.

The fix wasn't to find a shell that happened to exist on that image. It was to stop needing one: the inspector now exposes a callable and the skill imports it under Code Mode. Python is the one interpreter the sandbox guarantees, because the harness already runs its own client there.

The docs and the server disagreed about a path

Docs say skills land at /opt/tfy/skills/{name}. The running server logs /opt/tf/skills. My skill wouldn't have been found even with a working shell.

Small thing, twenty minutes lost, and I only caught it by reading the server's own startup log instead of trusting the documentation.

The model mattered more than the prompt

On a mini-class model, the agent skipped the tarball inspection entirely. It has registry tools that answer in a second and a sandbox step that doesn't, so it took the fast path and produced a verdict that had never looked inside the package.

Same instructions, same skill, on a larger model: loads the skill, runs the inspector, quotes the report back.

The mini model was never wrong about anything it said. That's the problem. It sounded equally certain having looked at strictly less. I now pin the model in the README and say why.

Switching is a one-line change, which is part of why this bit is easy to get wrong nothing stops you running the cheap one and believing the output.

It cried wolf on express

My first working inspector flagged express the most ordinary package in the ecosystem for URLs in package.json and a read of NODE_ENV.

That's useless. A tool that panics about express teaches you to ignore it, and then the one real finding gets ignored too. Three rounds of tightening later: express, chalk and ms come back completely silent, while esbuild reports its postinstall, child_process use and network egress all true, and the right answer there is admit with conditions, not refuse.

The regression I care about now isn't a missed finding. It's a benign package starting to produce them.

Qodo kept catching my own fixes

Every change went through a pull request reviewed by Qodo. Thirty-three findings across eight PRs.

The ones that stung were the second-order ones bugs my earlier fixes introduced:

I added extraction size caps to stop decompression bombs. Those caps then let a truncated repository tree manufacture false critical findings.
I capped severity in response. That went too far the other way and understated a proven content mismatch.
I taught the scanner to read .sh files, but forgot to extend the provenance check so shell scripts ended up half-examined.
My reconnect logic had the initial stream outside the try block. So a dropped connection skipped the reattach loop entirely: the one failure it existed to survive was the one that got past it.

And my favourite, caught the day of submission: I'd written a report template that always referenced a "limitations" card, then instructed the agent to omit that card when there were no limitations. An undefined reference in OpenUI renders as nothing at all. So clean audits express, ms, chalk would have produced an empty report on camera, while packages with problems rendered fine.

The good case was the broken one. I'd have found that during the demo.

I disagreed with two findings and said why in the thread rather than quietly changing code. One claimed the SDK returned turns newest-first; I checked against a real two-turn session and it's oldest-first. I still rewrote that code to not depend on ordering at all, which is the durable fix either way.

Would I hand this job to an agent again

Yes, but narrowly.

What makes this work isn't that the model is clever. It's that the harness gave it a place to run dangerous code, a way to reach real data, and a hard stop before the irreversible bit. Take any of those away and it's a chatbot with opinions about npm.

The part I'd still tell people to be careful about: the agent is most convincing when it has done the least work. Both times mine produced a confident wrong-shaped answer the missing bash, the mini model the output looked great. It was the tool traces that gave it away.

Code's all open source, MIT: https://github.com/imarpanpatra/portcullis
Demo: https://youtu.be/t042CZAsOuM

(Built with AI assistance, implementation and working through review findings. The design decisions, severity calibration and the calls on each review finding were mine.)