Question 1

The security team says "our code must not go to an external service". How do you respond?

Accepted Answer

Don't push back — accept the concern and present concrete options. The decision isn't yours, but laying out the options is your job. First clarify: what is the concern — retention, use for training, or egress at all? Different concerns have different answers. The options: 1. Contract terms — business plans typically differ on data retention and use. Legal can verify this. 2. Through the company's own cloud provider — in some configurations the model runs under the company's existing cloud agreement. This is often acceptable to security teams because data doesn't leave the existing trust boundary. 3. Scope restriction — no agent in sensitive modules (payments, PII processing), agent everywhere else. This can be enforced technically in managed settings. 4. Deny rules so secrets never enter the context at all. What I would not do: route around the restriction, or argue "everyone uses it anyway". That destroys trust. Finish by proposing that the decision be documented and enforced through managed settings.

Question 2

What layers would you set up so secrets don't reach the agent in an Android project?

Accepted Answer

Build the layers and state each one's limit — that shows depth: 1. .gitignore so secrets never reach the repo. Limit: the file stays on disk and the agent can read it. 2. permissions.deny to block reads: .jks, local.properties, google-services.json, .env, secrets/. Also Bash(env) and printenv — environment variables are a secret channel too. Limit: it only catches paths you list. 3. Managed settings so the critical deny rules sit at organisation level and can't be overridden. 4. Secret scanning in CI to catch a secret in a commit. Limit: the leak already happened. 5. Habit — sanitising logs and screenshots before pasting. Limit:* it depends on people, so onboarding and examples are needed. Add the crucial nuance at the end: none of these layers catches what a human pastes. So team training needs a real example — "don't paste a log like this, paste it like this".

Question 3

A developer gave the agent a test fixture containing sensitive customer data. What do you do?

Accepted Answer

Handle the incident, then fix the cause — the order matters. Immediately: 1. Determine how much data was exposed — one file or more. 2. Trigger the company's incident procedure. That decision isn't yours; reporting is. 3. Identify whose data it was; a notification obligation may apply. The cause (this is the real work): Why was real customer data in a test fixture? That problem predates the agent by a long way. If real data is in the repo, it is already on every developer's machine, in every clone and every backup. The fix: anonymised or synthetic test data. That fix is independent of the agent. Layers: A deny rule on the fixture folder (a stopgap). Scanning for PII patterns in CI. A team rule for how test data gets created. Tone: don't blame the developer. They surfaced an existing problem — real customer data should never have been in a test folder. That framing is both fair and the reason future incidents get reported rather than hidden.

Layer	What it does	Its limit
`.gitignore`	Keeps secrets out of the repo	The file stays on disk — the agent can still read it
`permissions.deny`	Blocks the agent from reading it	Only catches the paths you list
Managed settings	A developer cannot override it	Requires organisation-level deployment
Secret scanning (CI)	Catches a secret in a commit	It runs after the leak has already happened
Attention to context	Sanitise logs and screenshots before pasting	Depends on human habit

Privacy, secrets and corporate constraints

📚 Sources and documentation