Securing the Agent Platform: Admins, Credentials, Logs

A hosted agent platform holds the connections, credentials and publishing rights that let AI agents act across your business, so whoever controls its admin plane can create agents that read, send and change data with your organisation's authority. Agent platforms are the managed services where teams build, configure, connect and run agents: they store tool and connector credentials, register MCP servers, issue or map agent identities, hold model keys, keep memory and knowledge stores, and decide who can publish an agent to staff or customers. This guide is for AI platform owners, identity architects and security engineers responsible for such a platform. It covers tenant admin roles, agent identities, tool credentials, publishing controls, logs, hardening and lifecycle. It does not cover code-level framework security, which is in the Securing Agent Frameworks Guide, or the runtime design in the AI agent runtime reference architecture. It is vendor-neutral: confirm the exact setting names in your vendor's documentation.

Key takeaways

The admin plane is a privileged identity system. Anyone who can create connections or change an agent's tools can act with every credential the platform holds, so treat tenant admin like identity provider admin.
Give every agent its own identity. Distinct, inventoried agent identities with owners make permissions, logs and revocation possible; shared service accounts across agents make all three fail.
Prefer delegated, scoped tool access over shared keys. Per-user delegation or narrowly scoped workload credentials limit what a hijacked agent can reach, and the platform should never pass a user's token straight through to downstream APIs.
Control publishing and connections, not just building. Who can publish an agent organisation-wide or externally, and who can add a new MCP server or connector, are the decisions that change risk most.
Keep two logs and keep them elsewhere. Admin changes and agent actions both need to land in a store platform admins cannot alter, correlated by agent identity.

What the platform holds

OWASP LLM06:2025 Excessive Agency names three root causes: excessive functionality, excessive permissions and excessive autonomy. On a hosted platform, all three are set in the admin plane rather than in code, which is why that plane needs the most protection. MITRE ATLAS lists techniques that target exactly what the platform stores, including AML.T0083 Credentials from AI Agent Configuration and AML.T0098 AI Agent Tool Credential Harvesting.

Component	What it holds or can do	If an attacker controls it	Primary control
Tenant console and settings	Roles, environments, policies, data boundaries, integrations	Adds admins, relaxes guardrails, disables logging	SSO with phishing-resistant MFA, few admins, privileged access workstations
Connections and tool credentials	OAuth grants, API keys, database and SaaS credentials used by tools	Acts in connected systems with stored authority (AML.T0098)	Delegated or scoped credentials, vaulting, approval for new connections
Agent definitions	Instructions, tool lists, knowledge sources, autonomy settings	Re-purposes a trusted agent to exfiltrate or act (AML.T0086)	Change control, versioning, review before publishing
Agent identities	Platform-issued or mapped identities agents use downstream	Impersonates agents, persists with added credentials	One identity per agent, owner, expiry, recertification
MCP server and tool registry	Which servers and tools agents may call	Introduces a malicious server or tool	Allowlist, trust assessment, approval to add
Memory and knowledge stores	Indexed documents, conversation memory	Data theft or context poisoning (AML.T0080)	Per-agent and per-user scoping, source permissions honoured
Model and provider keys	Spendable model access	Spend abuse, data routed to other models	Platform-managed keys, spend caps, model allowlist
Publishing and channels	Who can use an agent: team, organisation, customers	Exposes an over-privileged agent to many users or the internet	Approval for broad or external publishing

Tenant admin roles and console access

Role design: separate tenant administrator (settings, roles, environments, data policies), connection administrator (creates and approves connectors and credentials), agent builder (designs agents in development environments), publisher (promotes agents to production and wider audiences), auditor (read-only logs) and operator (pauses agents, handles incidents). Builders should not be able to create new connections with standing credentials on their own.
Environments: separate development, test and production environments with different connections. Development agents use test data and test credentials; production connections are created only by connection administrators.
Authentication: SSO with phishing-resistant MFA, role assignment from identity provider groups and one tested break-glass account. The CISA and FBI Secure by Demand guide suggests asking whether SSO is offered at no additional cost and whether MFA or passkeys are on by default. See the Break-Glass Account Guide.
Trusted devices and elevation: the NCSC secure system administration principles ask you to trust your management devices, protect administration interfaces, take privileged access away when it is not needed and log all administration. Administer from privileged access workstations and grant tenant and connection admin just in time. See the Privileged Access Workstations Guide.
Review: review admin, connection admin and publisher assignments every quarter (our recommendation) and on every leaver.

Agent identities

Platforms take different approaches: some issue a first-class agent identity in your directory, some run every agent under one platform service principal, and some act only with the signed-in user's delegated rights. Know which model each agent uses, because it decides what logs show and what you can revoke.

Model	Good for	Watch for	Control
Per-agent identity issued in your directory	Autonomous and scheduled agents	Identities created outside joiner-mover-leaver processes	Owner, sponsor, expiry and recertification for each agent identity
Delegated user access (on-behalf-of)	Assistants acting for the signed-in user	Agent inheriting everything the user can do	Scoped delegation, consent per connection, short-lived tokens
Shared platform service account	Simple pilots only	All agents look identical in logs; one compromise exposes every connection	Migrate to per-agent identities before production

Register every agent: record agent, owner, purpose, identity, tools, data sources and audience in an agent registry, and block publishing of unregistered agents. See the AI agent registry.
Recertify: review agent identities and their permissions on a schedule and when the owner leaves. See Agent Identity Recertification and the Agent Identity and Access Guide.

Tool credentials and connections

In our view, the connection store is the platform's most valuable asset. Design it so that a stolen agent configuration or a hijacked agent gives the attacker as little as possible.

Delegate or scope: prefer per-user delegated OAuth where the agent acts for a person, and narrowly scoped workload credentials where it acts for itself. Avoid organisation-wide API keys stored once and shared by every agent that uses the connector.
No token passthrough: the MCP security best practices state that MCP servers must not accept any tokens that were not explicitly issued for the MCP server, and explain that passthrough bypasses controls and breaks audit trails. Apply the same rule to any platform-hosted tool: exchange tokens for downstream audiences rather than forwarding them.
Minimise scopes: the current (2025-11-25) revision of the same guidance warns against wildcard or omnibus scopes and recommends a minimal initial scope set with incremental elevation. Review every connection's scopes before it reaches production.
Vault and inject: keep credentials in the platform's secret store or your own vault, never in agent instructions or knowledge files, and inject at call time so the model never sees them. See Runtime Secrets Injection for AI Agents Without Prompt Exposure and the Credential Vaulting for AI Agents Guide.
Rotate and expire: set expiry on every stored credential and rotate static keys at least every 90 days (our recommendation). See the AI Agent Credential Lifecycle and Rotation Guide.
Approve new connections: adding a connector or MCP server to production needs a connection administrator and a trust assessment. See the MCP Gateway and MCP Server Governance Guide and MCP Server Trust Assessment.

Publishing, autonomy and guardrail settings

Audience tiers: require publisher approval to move an agent from its builder to a team, from a team to the whole organisation, and from internal to external or anonymous channels. External publishing is the highest tier.
Version and review: agent instructions, tool lists and knowledge sources are configuration that changes behaviour; version them, show diffs and require review before production.
Autonomy limits: require human approval for payments, deletions, external messages, permission changes and bulk actions, and set per-agent action and spend limits. See the Agent Controls and Monitoring Guide.
Guardrail changes are admin changes: disabling content filters, data loss rules or approval steps should require the tenant administrator role and raise an alert.
Code execution: if agents can run code, confirm it runs in an isolated sandbox with no standing credentials and restricted egress. See the AI Agent Sandboxing and Code Execution Guide.

The platform's logs

Event to capture	Why it matters	Alert?
Role assignment, SSO change, environment created	Persistence and widened access (T1078)	Always
Connection or credential created, scope widened	New authority for agents (T1098.001)	Always in production
MCP server or tool added to an allowlist	New code path agents can call	Always
Agent published or audience widened	More users exposed to the agent	Organisation-wide and external
Instructions, tools or guardrails changed on a production agent	Behaviour change or disabled control	Always for guardrails
Tool call by agent identity, with parameters and result status	Accountability and misuse detection (AML.T0053)	On policy denials, new destinations and volume spikes
Bulk data read from knowledge or connected systems	Exfiltration via tool use (AML.T0086)	Above baseline

Export both: stream the admin audit log and agent activity logs to a SIEM that platform admins cannot alter. NIST SP 800-53 AU-9(2) covers storing audit records on a separate system and AC-6(9) covers logging privileged functions. Secure by Demand asks SaaS providers to keep security logs for at least six months at no additional charge.
Correlate by identity: each tool call should carry the agent identity and, where delegated, the user. Reconcile with the downstream system's own logs.
Reconstruct incidents: see Agent Activity Timeline Reconstruction from Tool Calls and Identity Logs.

Hardening and lifecycle

Stage	Security actions
Buy	Ask the Secure by Demand questions; confirm the agent identity model, delegated access support, credential storage, role granularity, environment separation, publishing approvals, audit and activity log export, data residency and model data use. See the AI Agent Security Platform RFP.
Deploy	Enable SSO first; create environments; restrict connection creation to connection admins; set default audience to the builder only; turn on log export on day one.
Run	Quarterly review of admins, connections, scopes, agent identities and published agents; credential rotation; kill switch test twice a year (our recommendation); retire unused agents.
Respond	Pause affected agents, revoke their identities and connection credentials, review admin and configuration changes since the first suspicious event, and check downstream systems for agent actions. See the AI Agent Kill Switch and Containment Guide.
Retire	Unpublish and delete agents, revoke OAuth grants and delete stored credentials, remove agent identities from the directory, purge memory and knowledge indexes, confirm data deletion in writing and export the logs you must keep.

Roll back a hardening change, such as narrowing a connection's scopes, by keeping the previous scope set documented and re-granting only the specific scope a failing tool needs, never by switching back to an organisation-wide key. Apply vendor security updates for any self-hosted components promptly and subscribe to the vendor's security advisories page.

Detection and measurement

Percentage of production agents with their own identity and a named owner (target: 100 per cent).
Number of tenant and connection administrators (target: five or fewer each, our suggestion).
Percentage of production connections using delegated or scoped workload credentials rather than shared static keys.
Stored credentials past expiry or rotation date (target: zero).
Percentage of organisation-wide and external publications with a recorded approval.
Time to pause an agent and revoke its credentials, measured in tests.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	Threat addressed
Tenant roles and admin access	AC-2, AC-6, AC-6(5)	PR.AA-05	T1078 Valid Accounts
Agent identities and tool credentials	IA-5, AC-6	PR.AA-01	AML.T0083, AML.T0098, T1528 Steal Application Access Token
Agent configuration and publishing	CM-3, CM-7	PR.PS-01	OWASP LLM06 Excessive Agency
Memory and knowledge stores	SC-28, AC-3	PR.DS-01	AML.T0080 AI Agent Context Poisoning
Audit and activity logs	AU-9(2), AC-6(9)	PR.PS-04	T1685 Disable or Modify Tools
Vendor and hosted service	SA-9, SR-3	GV.SC-07	T1199 Trusted Relationship

Common failure patterns

Builders create production connections: any maker can add a connector with an organisation-wide key, and agents inherit it.
One service account for every agent: logs cannot tell agents apart and revoking one means breaking all.
Secrets in instructions or knowledge files: credentials pasted into agent configuration are readable by the model and anyone with edit rights.
Publish to everyone by default: a test agent with broad tools becomes available organisation-wide or externally.
Unreviewed MCP servers: a new server is added to the allowlist because it was convenient, without a trust assessment.
Logs left inside the platform: admin and agent activity exist only in a console an attacker can change.

Practitioner checklist

Treat the agent platform admin plane as a privileged identity system and administer it from privileged access workstations.
Enforce SSO with phishing-resistant MFA, group-based roles and a tested break-glass account.
Separate tenant admin, connection admin, builder, publisher, operator and auditor roles, with separate environments.
Give every production agent its own registered identity with an owner, expiry and recertification.
Use delegated or scoped workload credentials for tools, forbid token passthrough and minimise scopes.
Keep credentials out of instructions and knowledge files; vault and inject them at call time.
Require approval for new connections, new MCP servers and organisation-wide or external publishing.
Export admin and agent activity logs to a store platform admins cannot change, correlated by agent identity.
Review admins, connections, agent identities and published agents every quarter, and test the kill switch.

Securing the agent platform itself: tenant admins, tool credentials, agent identities and logs