Models and agents

The models

Every agent runs an Anthropic Claude model reached exclusively through Amazon Bedrock. Nothing is self-hosted and there is no second provider. Each model identifier carries the EU inference profile prefix, so inference stays inside EU regions by configuration rather than by intent; for capacity and resilience a request may be served from more than one EU region, and nothing is persisted there.

Your content is not used to train models. Amazon Bedrock does not use prompts or outputs to train foundation models, and an organization-wide policy opts Taiga out of AWS AI services using its content. That is a mechanism, not a promise: it is set above the workload account and a project team cannot turn it off.

Different work gets a different model, sized to the task. We change models as better ones ship, and we do not list which model runs where, because that changes on an ordinary tuning commit and a page that went stale would tell you less than this sentence does. The provider and the EU boundary do not change with them.

The agents

Agents are grouped here by the stage of a run they serve rather than listed by name. The roster changes as the product does, and naming it here would only guarantee this page goes out of date. The column that matters is the third: whether a stage reads free-form content a person supplied, because that is where prompt injection would arrive.

Why the untrusted-input column matters

Specification capture and implementation read content a person supplied: what you type, and the repositories you point them at. The other stages consume artifacts the platform itself generated earlier in the run. Maintenance is the judgement call in that split, and we would rather show it than hide it: it touches a live repository, but reads only manifests and lockfiles, so it is classified as not reading free text.

That classification is not a description written after the fact. Every agent carries a user_input_facing field in the infrastructure that defines it, and that field is what selects the guardrail profile the agent runs under. The classification is the input to the control, not a note about it, which is why it is the thing worth checking rather than a list of agent names. It holds whatever the roster looks like on the day you read this.

The profile for user-facing agents includes prompt-attack detection; the backend profile does not, because prescriptive technical content sets it off constantly and an alert nobody trusts is worse than none. That layer sits on top of the controls carrying the surface today: tenant-scoped retrieval, least-privilege agents invoked only by the API, and output validated at the API layer. Both profiles are switched off while support cases with AWS are open, which is recorded on our updates page and will be recorded again when they come back.

What an agent can reach

Agents are invoked by the API, never directly by a browser, and authenticate with IAM. They run on a private network with no inbound path from the internet. Retrieval is scoped to the requesting tenant, so an agent cannot surface another tenant's documents. Agents in the design and planning stage query a Google developer-documentation service to ground technical decisions in current documentation; that call carries the question, not your code.

The coding agent reaches your repositories only through the GitHub App your organization installed, with the scopes you granted, in an isolated workspace created for that build and destroyed after it. Revoking the installation ends that access immediately and without our involvement.

The agents do not have the last word

Output is probabilistic. It can be wrong, incomplete, or unsuited to your purpose, and the same input will not always produce the same result. The specification, threat model, review gates, and audit trail exist to make output reviewable by someone competent to judge it. They do not make it correct. Review before production use is yours, and producing governance evidence does not move that judgement to us.

Shared responsibility

EU AI Act

Where you converse with an agent you are interacting with an AI system, and the artifacts a factory run produces are AI-generated. We state that plainly rather than leaning on it being obvious, which covers the Article 50(1) transparency duty. Article 50(2) asks that synthetic output carry marking that is machine-readable and detectable as artificially generated. Whether that duty reaches generated source code, rather than media a person could mistake for authentic, is unsettled. We are working it through with counsel and will state our position here once we have one, rather than asserting an answer in either direction today.

What this page deliberately leaves out

Two different things, for two different reasons. Tool names and signatures, prompt structure, and the internals of how an agent decides what to call: publishing those would be a map of where an injection should aim rather than assurance that it would fail. Individual agent names and which model each one runs: those change most weeks, and a page that quietly falls behind its own source is worth less than one that never claimed the detail. Your security team can go deeper under the system description, and the vulnerability disclosure policy puts the agents in scope for research inside your own tenant if you would rather test than read.

Contact

Questions about the agents or the models go to security@tai.ga