Ping Identity 企业个人代理访问控制：为 Claude 等个人代理建立身份与运行时管控

2026 年 9 月 1 日，Ping Identity 发布了 Enterprise Personal Agent Access——通过 PingOne Privilege 交付的端到端方案，把发现（discovery）、无凭据特权访问与运行时控制结合起来，覆盖 Claude 等桌面个人代理与 Claude Code 等编码代理。触发点是一组令人不安的数据：Gravitee 的《AI 代理安全状态报告》发现，48% 的生产 AI 代理在无保护状态下运行。员工和开发者已经把个人代理带进企业，无论是否获批——它们能接触到敏感信息、开发者资源与公司数据，而传统身份体系是为人类设计的，根本不知道「代理」是什么。

1. 个人代理正在绕过企业的身份边界

人类员工访问系统时要经过身份认证、设备合规、权限申请。个人 AI 代理则绕过了这一切：营销同事把合同粘贴给桌面助手，工程师让 Claude Code 直接读仓库、调内部 API，财务分析师用个人账号连 MCP 服务器。Gravitee 报告里 48% 的生产代理无保护运行，就是这个现实的量化。Ping 的方案先把这些代理「发现」出来——包括从未获批的影子 AI，然后给每个会话绑定背后的人类与设备。代理不是匿名的行动者，而是某个人的延伸。

# Discover personal agents running in your environment, including
# shadow AI that was never formally approved. Visibility first.
GET /pingone/privilege/agents/v1/discover?scope=enterprise
{
  "agents": [
    {
      "agent_id": "agt_claude_desktop_7f21",
      "type": "desktop_assistant",
      "product": "claude",
      "user": "u_maria@corp",
      "device": "mbp-042",
      "status": "active",
      "first_seen": "2026-08-21T09:14:00Z",
      "approved": false,
      "risk": "shadow_ai"
    },
    {
      "agent_id": "agt_codex_ci_88c2",
      "type": "coding_agent",
      "product": "claude-code",
      "user": "u_devops@corp",
      "device": "ci-runner-7",
      "status": "active",
      "first_seen": "2026-08-28T13:02:00Z",
      "approved": true,
      "risk": "managed"
    }
  ]
}

2. 四个问题定义运行时控制

Ping 首席执行官 Andre Durand 把问题浓缩成一句：企业要能回答「这个代理、在这台设备上、被允许做这个动作吗，事后能证明吗」。拆开是四件事：一是发现——哪些代理在跑，包括影子 AI；二是归属——每个会话背后是谁、哪台设备；三是授权——代理在行动瞬间能访问什么资源、执行什么操作；四是证明——敏感动作是否要求人工批准，异常能否实时撤销，事后能否审计。这四件事合起来，就是把「代理身份」做成与人类身份同等严格的一等公民。

# Associate every agent session with the user and device behind it.
# An agent is not an anonymous actor; it is an extension of a human.
{
  "session": {
    "id": "sess_a1b2c3",
    "agent_id": "agt_claude_desktop_7f21",
    "user": "u_maria@corp",
    "device": "mbp-042",
    "started_at": "2026-09-01T10:00:00Z",
    "context": {
      "mcp_servers": ["internal-db-mcp", "hr-portal-mcp"],
      "repos": ["payments-core"],
      "k8s_clusters": ["staging"],
      "cloud": ["aws:dev"]
    }
  }
}

3. 为什么无凭据访问是关键设计

个人代理最大的风险不是模型本身，而是它携带的凭据。如果 Claude Code 的配置里存着一条长期有效的 token 或 API key，一旦会话被提示注入或越权，攻击者就拿到了一把万能钥匙。无凭据特权访问（secretless privileged access）的思路是：代理会话启动时，向身份平台换取绑定该会话的短时、作用域受限凭据；代理要访问某个资源时，先经过策略裁决再签发；异常行为触发实时撤销。结果：代理完成工作的全程不持有任何长期秘密，每笔操作都可追溯到会话与背后的人。

# Policy at the point of action: allow, deny, log, or ask a human.
# The question is not whether the agent is smart enough to act;
# it is whether the enterprise can see and control the action.
{
  "policy": "personal-agent-runtime",
  "rules": [
    {"resource": "repo:payments-core", "actions": ["read", "write"], "decision": "allow"},
    {"resource": "repo:payments-core", "actions": ["merge"], "decision": "require_human"},
    {"resource": "mcp:hr-portal", "actions": ["read_pii"], "decision": "deny"},
    {"resource": "env:prod", "actions": ["*"], "decision": "deny"},
    {"resource": "cloud:iam", "actions": ["write"], "decision": "require_human"},
    {"default": true, "decision": "log"}
  ],
  "revocation": {"on_anomaly": true, "on_risk_score_gt": 0.85}
}

4. 代码合入的身份归属

对开发者工作流，Ping 的方案带来一个直接变化：每次代码合入都落在「发起它的身份」之下——开发者或代理，而不是混在一起。代理活动归属于代理自身，而不仅仅是背后的用户。安全团队因此能得到一份记录：代理在什么时间、通过哪个会话、改了什么、以谁的名义。这意味着如果你要审计「这行 AI 写的代码是谁让它写的」，你查得到答案。工程团队也可以在合入前把代理提交送入代码审查工具，让自动化先于人类把关。

5. 个人代理能碰到什么：远超聊天窗口

Ping 特别提醒：个人 AI 代理能触达的范围远超 AI 应用本身——MCP 服务器、代码仓库、内部服务与 API、Kubernetes 集群、数据库与云基础设施。一个桌面助手的「帮我查一下订单」可能触发一连串数据库与内部 API 调用。这也是为什么管控必须在「动作发生的那一刻」执行：在受管资源前面套上策略层，决定允许、拒绝、记录、要求人工批准或实时撤销。安全团队不需要禁止 AI，只需要保证代理的每一步都走在自己能看见的路上。

// Secretless privileged access: exchange the session for short-lived
// credentials bound to the agent, never a long-lived key.
async function accessTokenFor(session, resource) {
  const decision = await ping.policy.evaluate(session, resource);
  if (decision !== 'allow') {
    throw new PolicyDenied('action on ' + resource + ' -> ' + decision);
  }
  // Token is scoped, short-lived, and attributable to the session.
  return ping.privilege.issue({
    sessionId: session.id,
    resource,
    ttl: '15m',
    revokeOnAnomaly: true,
  });
}

6. 现在该做什么

第一，做一次代理盘点：企业中运行着哪些个人代理与影子 AI？它们能碰到哪些系统？第二，为代理会话建立身份归属：把每个代理动作绑定到背后的用户与设备。第三，用短时作用域凭据替换长期 token，敏感动作配置人工批准。第四，把代理合入的代码纳入审查流程，用代码审查工具做第一轮检查。最后，别把这件事留给安全团队单独推动——开发者、平台与安全需要一起定义「代理能做什么」的策略，因为代理安全的本质，是把身份与治理从人延伸到机器。具体落地时，先从风险最高的一对组合开始：能触达生产仓库的编码代理，或通过 MCP 访问内部数据的桌面助手；在那里试点两周，公开学到的东西，让策略从真实使用中长出来，而不是从恐惧中长出来。把代理身份当作普通工程问题而非安全特例的组织，一旦各厂商都交付代理原生的控制能力，它们会跑得最快。

# Audit: every commit lands under the identity that made it, and
# agent activity is attributable to the agent, not just the user.
{
  "commit": "9f2c81a",
  "repo": "payments-core",
  "session": "sess_a1b2c3",
  "agent_id": "agt_claude_desktop_7f21",
  "user": "u_maria@corp",
  "actions": [
    {"ts": "2026-09-01T10:04:12Z", "tool": "read_file", "target": "src/api/v1/refund.ts"},
    {"ts": "2026-09-01T10:05:40Z", "tool": "write_file", "target": "src/api/v1/refund.test.ts"},
    {"ts": "2026-09-01T10:06:02Z", "tool": "git_commit", "decision": "allow", "attribution": "agent:agt_claude_desktop_7f21"}
  ],
  "credential_used": {"type": "short_lived", "ttl": "15m", "expired": false}
}