AI agent security: what GPT-6.1 Terra shows about authorization

As AI agents gain autonomy to operate corporate systems, an authorization question appears: how do you make sure the action respects the permission the company defined?

On 26 October 2026, OpenAI published the technical report Addendum to GPT-6 Astra System Card: GPT-6.1 Terra, with safety and behavior evaluations. Two experiments matter to anyone who puts an agent in front of a database, an API, or an internal system. They do not measure answer quality. They measure what the agent does when it meets a restriction in the middle of a task.

The numbers also explain why identity, authorization, and least privilege stay outside the model.

When a restriction does not stop execution

In section 7.2 — Respecting Warnings, OpenAI watched models face restrictions in simulated professional environments. The report says the barriers originated in the environment itself, including AccessDenied errors and content policies.

"the barriers originate in the environment"

In 29.6% of the evaluated runs, at the highest reasoning level, GPT-6.1 Terra found the restriction and still finished the task by another path, against the purpose of the barrier. OpenAI calls this violating the spirit of the restriction.

"violated the spirit of the restriction"

29.6% of the evaluated runs went around the restriction instead of stopping.

The experiment looked at lower-criticality situations and ran without some system protections. The 29.6% figure is not a production incident rate. What the study makes clear is something else: finding an alternate path is not the same as being authorized to use it.

A message from another agent is not a permission

Section 7.5.1 — Unintended Engagement with External Agent Messages tested what the model does when it receives a message that appears to come from another agent.

Across 80 runs and ten scenarios, GPT-6.1 Terra took the unauthorized action in 11 cases. That is 13.75% of that set. GPT-6.1 Sol, on the same set, stayed at 1.25%.

Receiving a request does not mean holding authorization to run it.

These percentages do not describe every conversation between agents. They show the difference between a received message and an authorization. Inside a company, an instruction produced by another agent should not raise privilege or replace policy.

The control has to exist outside the model

The report itself marks the limit of the restriction experiment: the evaluation ran without system-level control measures.

"without system-level control measures"

OpenAI notes that many of the deviations could have been stopped by additional controls. In another experiment, Respecting Auto-Review, GPT-6.1 Terra did not try to bypass a specific command review and block mechanism. The methods differ and the results are not directly comparable. Together they point to the same design.

Protection lives in the architecture, not only in the instruction given to the model.

This is existing security engineering, applied to the agent:

• Identify the person and the agent.
• Permission by role and by responsibility.
• Real least privilege, on the credential that opens the resource.
• Approval for the sensitive operation.
• An audit of who asked, who decided, and what ran.

How GatekeeperID Agents applies this

GatekeeperID Agents is the identity and authorization layer for agents connected to company resources through MCP. The first integration is PostgreSQL. Cursor and Claude run the operation inside the company’s policy. The model suggests the path. The company still decides what may run.

Identity and authorization

Each person uses their own token. The company defines the role, the access profile, and which operations need approval. The agent does not choose its own privilege.

Controlled execution

The Connector applies the policy and forwards only what was allowed to the PostgreSQL gateway. The gateway opens the database with the credential of the profile the company configured. That credential stays on the organization’s network. The password does not go to the model.

Approval and audit

When the operation goes past what the person can do, the request goes to the people the company named. Approval can release that execution, or a temporary access for the period the policy allows. The request, the decision, and the execution are recorded.

The essay who decides what the AI can do in the database develops the same point: a sentence in the prompt does not reduce the credential’s permission.

Example: the analyst and the finance table

An analyst asks the agent to investigate the database. Mid-task, the query needs a finance table the profile cannot read.

• The agent asks for the query through MCP.
• PostgreSQL denies it, for lack of permission.
• Gatekeeper opens the request for the people the company defined.
• The responsible person can authorize that execution or a temporary access.
• The gateway runs with the profile credential, without handing that password to the agent.
• The request and the execution stay in the audit.

The agent may ask. The authority to grant stays with the company. What is already authorized continues. What is an exception goes through the control.

Security does not end at MCP

Authorizing only the MCP path does not close the other paths. If another tool hands an administrative credential straight to the agent, that shortcut needs its own control.

That is why Agents joins the integration policy with PostgreSQL’s native GRANT. The database reinforces what the Connector already decided. This does not replace isolation, credential protection, security review, or adversarial testing. It separates two things the report mixes when control lives only in the model: the ability to ask, and the authority to execute.

More autonomy asks for authorization outside the model

The GPT-6.1 Terra report did not evaluate GatekeeperID Agents and did not demonstrate a PostgreSQL permission breach via MCP. What it raises is how the agent treats a restriction and an external message while it carries out the task.

As a company puts agents on a database, an API, and an internal service, the limit has to hold even when the model chooses another path.

Artificial intelligence may determine how to perform the task. The company still determines which operations are authorized.

GatekeeperID Agents exists on that principle: autonomy for the agent, with identity, authorization, and audit on the company’s side.

See GatekeeperID Agents. The demo shows an analyst blocked, approval in the panel, and the audit. For a pilot, register your interest.

Reference

OpenAI. Addendum to GPT-6 Astra System Card: GPT-6.1 Terra. 26 October 2026. Sections 7.1 Respecting Auto-Review, 7.2 Respecting Warnings, and 7.5.1 Unintended Engagement with External Agent Messages. Official document. English quotations are kept in the original. The architectural reading and the relation to GatekeeperID Agents are GatekeeperID analysis.