Access Governance

The Problem

If every agent reads the same twin and every user can invoke any agent, then by default every user has access to every metric. A Support Manager's retention agent could ask the Finance twin for Customer Acquisition Cost (CAC). A sales rep's pipeline agent could read the pipeline of colleagues in other territories. Without governance the twin becomes a way around the access controls your security team has already built.

Enterprise access control is an old problem with well-tested answers: role and attribute policies, row-level security and delegated tokens. GASP's job is to give those answers a shared vocabulary for metrics.

The Three-Layer Model

Access control in an agentic system happens at three layers. Each one is enforced in a different place, so keep them separate when you design permissions.

What GASP Adds

Two metric-level classifications give downstream policy systems stable identifiers to reference. They are recommendations for your own policy systems to enforce.

Sensitivity Tier

Aligns with ISO 27001, OSSA data_classification and AWS Cedar common patterns. See the glossary entry for the canonical definition.

Access Scope

Describes whether a metric is naturally filterable per user context (the ReBAC/ABAC dimension). See the glossary entry for the canonical definition.

Recommended Classifications

Default sensitivity and scope for the 69 metrics in the GASP relationship graph. The other 244 metrics carry no recommendation yet; classify them with the decision framework below. Use these as a starting point. Your organisation's risk profile may justify different choices.

A Decision Framework

When classifying a new metric, work through three questions in order:

1. Who needs it by default? If the answer is "the whole company," the tier is internal. If the answer is "managers and above," it is confidential. If it is "finance leadership and the CEO," it is restricted.
2. Is it filterable? If the same metric makes sense with per-user context (my pipeline, my accounts, my team's tickets), give it a scope other than unscoped. A sales rep should see pipeline but only their own.
3. Does computing it leak something the value alone does not? Aggregate marketing spend is less sensitive than per-campaign spend. Aggregate CAC is less sensitive than CAC broken down by channel. Publish the aggregate and restrict the breakdowns that expose competitive detail. Breakdowns are declared in the canonical formulas (CAC by cost centre, Win Rate by channel). The recommended tier and scope apply to the metric as a whole, so your policy can set a stricter tier on a breakdown.

Integration Patterns

GASP tags are metadata, read by the policy systems that do the enforcing. Four patterns cover most implementations.

Cedar Policies

Cedar is an open-source policy language used by AWS Verified Permissions and referenced in the OSSA governance schema. Express GASP classifications as resource attributes:

// Principal: User with department and clearance attributes
// Resource: GASP metric with sensitivityTier and accessScope

permit (
  principal in Department::"Finance",
  action == Action::"query",
  resource
)
when {
  resource has sensitivityTier &&
  resource.sensitivityTier in ["public", "internal", "confidential", "restricted"]
};

// Department managers see internal + confidential for their dept
permit (
  principal,
  action == Action::"query",
  resource
)
when {
  principal has role && principal.role == "manager" &&
  resource.sensitivityTier in ["internal", "confidential"] &&
  (resource.accessScope == "unscoped" ||
   resource.department == principal.department)
};

// Everyone sees internal + unscoped
permit (
  principal,
  action == Action::"query",
  resource
)
when {
  resource.sensitivityTier == "internal" &&
  resource.accessScope == "unscoped"
};

// Restricted tier: explicit allowlist only
forbid (
  principal,
  action == Action::"query",
  resource
)
unless {
  resource.sensitivityTier != "restricted" ||
  principal in Group::"FinanceLeadership"
};

Open Policy Agent (Rego)

OPA is a CNCF graduated policy engine and a common choice for policy-as-code in large companies. The same GASP classifications expressed in Rego:

package gasp.authz

import rego.v1

default allow := false

# Everyone sees internal + unscoped metrics
allow if {
  input.resource.sensitivityTier == "internal"
  input.resource.accessScope == "unscoped"
}

# Department managers see confidential within their department
allow if {
  input.principal.role == "manager"
  input.resource.sensitivityTier in {"internal", "confidential"}
  manager_can_see_scope
}

manager_can_see_scope if input.resource.accessScope == "unscoped"
manager_can_see_scope if {
  input.resource.accessScope == "department-scoped"
  input.resource.department == input.principal.department
}
manager_can_see_scope if {
  input.resource.accessScope == "owner-scoped"
  input.resource.owner == input.principal.user_id
}

# Restricted requires explicit finance leadership membership
allow if {
  input.resource.sensitivityTier == "restricted"
  "finance_leadership" in input.principal.groups
}

Warehouse Row-Level Security

Row-level security is where enforcement reaches the data. Snowflake, BigQuery and Postgres all support it, filtering the result set by the user's identity. You can generate the policies from GASP classifications.

-- Snowflake: owner-scoped pipeline visibility
-- "Owner" can be an individual rep, a territory, a book or a segment.
-- Interpretation lives in the ownership_assignments table, not in GASP.
CREATE ROW ACCESS POLICY pipeline_owner_policy AS (owner_id VARCHAR)
  RETURNS BOOLEAN ->
    CASE
      WHEN CURRENT_ROLE() IN ('SYSADMIN', 'FINANCE_LEADERSHIP') THEN TRUE
      WHEN CURRENT_USER() IN (
        SELECT user_id FROM governance.ownership_assignments
        WHERE assigned_owner_id = owner_id
      ) THEN TRUE
      ELSE FALSE
    END;

ALTER TABLE fct_opportunities
  ADD ROW ACCESS POLICY pipeline_owner_policy ON (owner_id);

-- BigQuery: restricted-tier column masking via data policy
CREATE OR REPLACE TABLE company_metrics OPTIONS (
  policy_tags_on_columns = [
    ('burn_rate',  'projects/acme/locations/us/taxonomies/gasp/policyTags/restricted'),
    ('operating_margin', 'projects/acme/locations/us/taxonomies/gasp/policyTags/restricted')
  ]
);

MCP OAuth Scopes

An agent always acts on behalf of a user and inherits that user's scope through a delegated identity. The 23 GASP MCP tools return model-layer information, SQL text and Ossie documents; the only values they compute come from GASP's synthetic dataset, so one read scope covers them all. Gate the tool that runs SQL against your warehouse instead: map GASP sensitivity tiers to OAuth scopes on that executor and let warehouse row-level security apply the access scope.

// OAuth scopes: one read scope for the GASP MCP tools.
// run_query is your SQL executor, the only tool that returns values;
// each metrics:query scope admits metrics of that GASP sensitivity tier.
{
  "scopes": {
    "gasp:read": ["lookup_metric", "lookup_definition", "list_metrics",
                  "get_formula", "get_relationships", "get_data_requirements",
                  "search", "generate_query", "validate_mapping", "validate_adapter",
                  "compile_model", "score_drift", "profile_schema", "propose_mapping", "record_decision", "derive_cel", "generate_checks", "plan_fixes", "infer_drivers", "explain_path", "coverage_gap"],
    "metrics:query:public":       ["run_query"],
    "metrics:query:internal":     ["run_query"],
    "metrics:query:confidential": ["run_query"],
    "metrics:query:restricted":   ["run_query"]
  },
  "role_scopes": {
    "ic":       ["gasp:read", "metrics:query:public", "metrics:query:internal"],
    "manager":  ["gasp:read", "metrics:query:public", "metrics:query:internal",
                 "metrics:query:confidential"],
    "exec":     ["gasp:read", "metrics:query:public", "metrics:query:internal",
                 "metrics:query:confidential", "metrics:query:restricted"]
  }
}

Agent Integration Patterns

The protocols covered above handle single-user data access. Agentic systems add a second identity layer: agents act on behalf of users but have their own permissions too. OSSA (agent contracts) and A2A (inter-agent communication) meet GASP at that second layer.

The Three-Ceiling Model

A common mistake in agentic systems is letting agents run with service accounts that have more access than the user who invoked them. Effective access is the intersection of three ceilings:

• Agent clearance comes from the OSSA manifest (authorization.clearance_level)
• User clearance comes from your identity provider (Okta, Google Workspace, Azure AD)
• Metric sensitivity comes from GASP (accessControl.classifications)

The warehouse enforces the intersection through row-level security and column masking. The agent and the application describe the constraints and the warehouse computes the answer.

Token Propagation (A2A)

When a coordinator agent calls a specialist via A2A, the user's token must propagate through the call chain. If the coordinator uses its own service token, privilege escalates silently. The pattern is OAuth 2 Token Exchange (RFC 8693):

// Coordinator receives a request with the user's token
// It does NOT use its own service token to call specialists

// 1. Coordinator exchanges the user token for a delegated token
//    scoped to the specialist audience
POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&audience=https://agents.acme.com/retention-specialist
&actor_token=
&actor_token_type=urn:ietf:params:oauth:token-type:access_token
&scope=gasp:read metrics:query:confidential

// 2. Coordinator calls the specialist with the delegated token
POST https://agents.acme.com/retention-specialist
Authorization: Bearer 
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": "req-coord-001",
  "method": "SendMessage",
  "params": { "message": { "messageId": "msg-coord-002", "role": "ROLE_USER", "parts": [...] } }
}

// The specialist now executes warehouse queries with the ORIGINAL user's
// identity. If the user cannot see restricted metrics, neither can the
// specialist acting on their behalf. No privilege escalation via chaining.

Human Review for Restricted Access (OSSA)

OSSA's governance.authorization marks which tools need a human approval and which policies the agent must follow. Together with a policy that reads the GASP tier tag, this is a cheap safety valve for the restricted tier:

# In the agent's .ossa.yaml manifest
apiVersion: ossa/v0.5.6
kind: Agent
metadata:
  name: gasp-retention-analyst

governance:
  authorization:
    clearance_level: 3          # handles up to confidential on its own
    tool_permissions:
      - tool: lookup_metric     # reads the twin: never gated
        risk_level: low
        requires_approval: false
      - tool: run_query         # your SQL executor
        risk_level: high
        requires_approval: true # the runtime pauses for a reviewer
    policy_references:
      - gasp.restricted_metrics_require_review   # approves unless a metric is restricted

cognition:
  governance:
    audit_required: true
  alignmentGate:
    enabled: true
    arbiter: human
    timeout: 4h

When the retention agent, asked to explain a Net Revenue Retention (NRR) drop, requests Burn Rate (a restricted metric) for context, the OSSA runtime pauses the query and asks a reviewer in Finance Leadership. The user sees "waiting for review" rather than getting the number silently. The manifest says only that the query tool is approval-gated. The referenced policy decides when, and all it has to compare is the GASP tier tag on the metrics in the request, so a query over public and internal metrics goes straight through. OSSA's own human_review_triggers fire on reasoning signals (low confidence, a contradiction, branch depth), so the tool gate lives in governance.authorization instead.

The Audit Tuple Requirement

Traditional warehouse audit logs capture one identity: whoever ran the query. In agentic systems you need three: the user who asked, the agent that ran and the session that connected them. With only the first, the day an agent does something unexpected you can see the query but cannot tell who asked for it.

-- Extend warehouse queries to carry the full identity tuple
-- Snowflake query tag example
ALTER SESSION SET QUERY_TAG = OBJECT_CONSTRUCT(
  'user_id',     'user-sarah-cfo',
  'agent_id',    '[email protected]',
  'session_id',  'a2a-ctx-abc-123',
  'parent_task', 'task-coord-001',
  'gasp_metric', 'nrr',
  'tier',        'confidential'
)::STRING;

-- Then correlate across four log sources:
--   1. Identity provider (user authentication)
--   2. A2A message log (agent invocations)
--   3. MCP server log (tool calls)
--   4. Warehouse query log (actual data access)
-- Joined on session_id, you get the complete chain from
-- "user Sarah asked a question" to "specifically these rows were read".

OSSA and A2A have no standard audit format yet. GASP recommends propagating the tuple on every call, joining the four logs on session_id and keeping them as long as your compliance framework requires (typically 90 to 365 days).

Who Does What

Common Dilemmas

What GASP Does Not Do

GASP is a standard, not a runtime. Specifically:

• GASP does not enforce permissions. Enforcement belongs in Cedar, OPA, your identity provider or your warehouse.
• GASP does not define user roles. Your organisation designs its own role hierarchy and GASP gives those roles a vocabulary to reference.
• GASP does not audit access. Audit logging happens where queries run (the warehouse) and where tokens are issued (the identity layer).
• GASP does not replace your data governance program. It complements SOC2, ISO 27001 and existing compliance frameworks.

GASP adds the shared vocabulary. Once every metric has a stable ID, a recommended tier and a recommended scope, policies move between tools: a Cedar policy written against GASP metric IDs works the same on Snowflake or BigQuery, with Okta or Google Workspace as the identity provider.