AI agent privileged access needs two owners

Giving an AI agent production credentials is a management decision expressed through a technical control. A fractional CTO can decide that the agent needs a capability to ship or operate the product. A security lead can decide what conditions make that capability tolerable. Either role acting alone leaves a gap: security cannot accept business risk on behalf of the company, and technology leadership should not grade its own controls.

That split sounds tidy until an agent needs to merge code, change cloud resources, read customer records, or trigger a payment. The useful question is not which title owns privileged access in the abstract. It is who decides the purpose, who writes and tests the boundary, who approves each class of action, and who commands the response when the agent behaves outside that boundary.

I treat an agent as a nonhuman workload with a large and unpredictable instruction surface. It may plan correctly and still call the wrong tool. It may follow malicious content retrieved from a ticket or document. It may also do exactly what someone requested while violating a policy that nobody encoded. That is why ordinary service account practice is necessary but insufficient. The credential matters, yet the allowed action, runtime context, approval path, and evidence matter just as much.

Ownership splits by decision type

A fractional CTO should own why an AI agent receives access, while a security lead should own how that access is constrained and checked. The CEO or another accountable executive retains acceptance of material company risk. This is a separation of decision rights, not shared ownership where everyone can assume someone else acted.

Several decisions often get collapsed into one approval ticket. They need different owners and records:

• The fractional CTO accounts for the business purpose and expected benefit, supported by the product and engineering owner and a written success measure.
• The security lead accounts for permitted resources and actions, supported by the system owner, a versioned access policy, and a threat review.
• The system owner accounts for production activation, supported by test results, a rollback path, and a named operator.
• The CEO or delegated executive accepts material residual risk through a time limited exception with a review date.
• The security lead or named responder commands a security incident and maintains the incident record and decision log.

This division is deliberately uneven. Business authorization happens before control design, activation follows verification, and incident authority begins when a defined trigger fires. Each owner should know both the decision received from the previous role and the evidence owed to the next one. A missing record should trigger a stop because nobody can verify that the required decision happened or that its conditions survived implementation.

The distinction between accountability and administration matters. The engineer who creates a workload identity is administering access. The person who can explain why the agent needs to alter production is accountable for the use case. The person who specifies that it may update one deployment but never change identity policy owns the security boundary. Do not call the administrator the owner simply because that person clicked the button.

Small companies may put several roles on one person. The decisions still need separate moments and separate records. If the fractional CTO also acts as security lead, require another executive or system owner to approve high impact privileges. Separation of duties can exist in a workflow even when the org chart is thin.

This model also keeps contractors within a sane mandate. A fractional leader can design the system and make delegated operating decisions, but the company must name an employee or officer who can accept financial, legal, and operational consequences. A contract does not transfer corporate accountability by implication.

The fractional CTO owns purpose and architecture

The fractional CTO owns the agent's business mandate, system design, cost tradeoffs, and operating model. That role should answer what job the agent performs, why automation is preferable, what failure the product can tolerate, and which human team remains responsible for the outcome.

Start with capability, not credentials. Saying an agent needs cloud admin because it manages infrastructure skips the design work. Does it need to create preview environments, restart an existing service, alter network rules, read secrets, or delete a database? Those are different capabilities with different consequences. A good architecture turns the broad job into narrow operations before anyone opens an identity console.

The fractional CTO should also decide whether the agent may act directly or must prepare a change for a person to execute. Direct execution makes sense for frequent, reversible, observable work with a limited blast radius. A proposed patch or plan is better when the action is rare, destructive, hard to verify, or governed by a duty that belongs to a person. An agent that diagnoses a failed deployment can suggest a rollback without holding permission to rewrite identity policy.

This role owns the dependency map around the agent. That includes the model provider, orchestration service, tool gateway, source repository, deployment system, secrets broker, logging path, and human approval channel. If one component is unavailable, the architecture must fail in a defined state. An approval service outage should not silently convert supervised actions into autonomous ones.

Technology leadership also owns the economic argument. Privileged automation creates control costs: policy work, test environments, logs, on call coverage, credential rotation, and review. If a task happens twice a year, human execution may cost less and carry less risk. The popular recommendation to give an agent broad read access first and tighten it later is wrong. Broad discovery becomes a hidden dependency, so narrowing access later breaks workflows that nobody documented.

The CTO's approval should expire when the use case changes. Connecting a second repository, moving from staging to production, adding customer data, or allowing write operations creates a new authorization question. Model upgrades and prompt changes may also change behavior, but they do not automatically require new privileges. Tie reapproval to capability and consequence, not every software release.

A fractional engagement needs explicit authority in writing. State which environments the CTO may approve, the financial or operational thresholds that require a founder, and who can suspend an agent without consultation. Without that delegation, teams tend to accept chat messages as approval. That record will fail exactly when an incident becomes expensive and memories become selective.

The security lead owns boundaries and assurance

The security lead owns access policy design, threat analysis, control requirements, validation, monitoring requirements, and the security response process. This role should be able to block activation when the implementation does not match the approved use case. That is control authority, not authority to decide that the business should run the agent.

NIST defines least privilege as giving a user or process only the minimum resources and authorizations needed for its function. For agents, apply that principle at the action level. A credential limited to one cloud account can still be excessive if it can create identities, alter logs, and delete data within that account. Resource scope alone does not describe agency.

NIST Special Publication 800-207 makes a second useful distinction: authentication and authorization happen as separate functions before a session reaches a resource, and network location grants no implicit trust. I would extend that reasoning to each sensitive tool call. An authenticated agent process is not permanently authorized merely because its session began correctly. The policy enforcement point should reconsider the actor, requested action, resource, runtime state, and approval evidence.

The security lead writes the required control behavior in terms an engineer can test. Examples include short credential lifetimes, workload identity instead of a shared human account, an explicit deny for identity administration, environment boundaries, per action approval, immutable audit events, rate limits, and an emergency disable path. A document that says use least privilege without naming allowed and forbidden actions is not a policy engineers can implement.

Assurance means testing both expected and hostile paths. The lead should ask the agent to perform a permitted action, attempt a forbidden sibling action, reuse an expired approval, cross an environment boundary, and operate while logging or approval services are unavailable. The system should deny unsafe requests predictably and leave enough evidence to explain the denial.

The security lead should not personally hold every credential or approve every routine request. That creates a queue, encourages bypasses, and mixes policy ownership with daily administration. System owners can approve normal operations within a policy the security lead has reviewed. Security reserves direct approval for exceptions, new privilege classes, and actions with company wide consequences.

Policies must constrain actions, not titles

An effective AI agent access policy binds an identity to named actions, resources, conditions, and an expiration time. Job titles belong in the approval rule, not inside the runtime permission. The runtime has to decide whether this specific call is allowed.

A compact policy can look like this:

agent: release-bot-prod
purpose: deploy approved application builds
identity:
  type: workload
  session_ttl_minutes: 15
resources:
  allow:
    - service/payments-api
    - deployment/payments-api
  deny:
    - identity/*
    - secrets/*
actions:
  allow:
    - deployment.read
    - deployment.create
    - deployment.rollback
  deny:
    - deployment.delete
    - policy.write
conditions:
  source_ref: refs/heads/main
  artifact_attestation: required
  approval:
    deployment.create: service-owner
    deployment.rollback: on-call-engineer
limits:
  max_actions_per_run: 8
  max_parallel_runs: 1
on_control_failure: deny
expires: 2026-10-31

This fragment prevents several ordinary failures. The agent cannot turn a deployment job into identity administration. It cannot deploy an unapproved branch, reuse an unlimited session, or continue when the approval check fails. The expiration date forces a new decision instead of allowing an experiment to become permanent infrastructure.

Treat purpose as review evidence, not an enforcement control. A policy engine cannot infer that a requested action supports the prose. Engineers must map purpose to an allowlist. Deny rules are useful defense, but a denylist cannot rescue an open ended allow rule because new actions appear faster than reviewers update exclusions.

Keep model credentials separate from tool credentials. The token used to call a model should not grant cloud or repository access. The orchestration layer should exchange the agent's workload identity for a short lived, scoped tool credential only after the policy check. This reduces the damage from a leaked session and makes the audit event describe which capability the agent actually received.

Log the decision, not just the API call. Each privileged event should record the agent identity, requested action, target resource, policy version, approval identifier when required, result, timestamp, run identifier, and a digest of the input that caused the action. Avoid dumping full prompts or retrieved documents into a general log because they may contain secrets or customer data. Keep enough context to reconstruct the decision while applying the same data retention rules used for the underlying system.

OWASP's agentic AI guidance draws a line that teams often miss: excessive data access and excessive agency are different failures. Reading too much is a confidentiality problem. Performing high impact operations across connected systems can damage integrity and availability even when every read was authorized. Review those paths separately because one read only role can expose data, while one narrow write action can stop a service.

Approval should follow blast radius

Approval requirements should depend on reversibility, scope, sensitivity, and time pressure. Requiring a person to approve every action feels safe, but constant prompts train people to approve without reading. Human approval is a control only when the approver has context, time, and real authority to refuse.

I use three practical action classes. Routine actions are narrow, reversible, and well observed, such as restarting one stateless worker under an existing runbook. Sensitive actions touch production data or availability but have a tested recovery path, such as rolling back one service. Restricted actions alter identity, destroy durable data, weaken logging, change network trust, or move money. An agent should usually prepare restricted actions rather than execute them.

For a sensitive action, the approval request must show the proposed operation, exact target, reason, expected change, evidence used, policy result, and rollback. A message that asks approve agent action with a green button provides ceremony, not informed consent. Bind approval to a digest of the action so the agent cannot obtain consent for one request and execute another.

Standing privilege is acceptable only for the routine class, and even then it needs rate and scope limits. Sensitive access should be granted just in time for one task or a short session. Restricted access should require two people when the consequence can exceed one system owner's mandate. One approver should represent the system, and the other should represent security or company risk.

Emergency access needs a faster route, not a missing route. Define who may activate it, which actions it permits, how long it lasts, where it alerts, and when review occurs. If the incident commander can allow an agent to roll back a service during an outage, that permission should already exist as a tested policy variant. Do not invent emergency IAM while production is failing.

The security lead sets these classes and control requirements. The fractional CTO assigns business workflows to them with the system owner. A disagreement should go to the executive who owns the risk, documented as a time limited exception. Security should not quietly downgrade the class to help delivery, and the CTO should not relabel a restricted action as routine because the agent performs it often.

Incident command must be named before deployment

A security lead should command incidents involving credential compromise, policy bypass, unauthorized access, or hostile instruction. The fractional CTO should command recovery from an ordinary product or automation failure when no security boundary was crossed. When the facts are unclear, start under the security process because preserving evidence and containing access are harder to recover later than a few minutes of delivery speed.

NIST Special Publication 800-61 Revision 3 assigns different responsibilities to leadership and incident handlers. Leadership can authorize high impact actions such as shutting down or rebuilding important services. Incident handlers verify the incident, analyze evidence, limit damage, find causes, and support restoration. That supports a clean split: the security lead runs the response work, while the CTO or executive authorizes business consequences beyond the responder's mandate.

Consider a release agent that reads a poisoned issue description. The text instructs it to inspect environment variables and attach diagnostic output to a build record. The agent's repository token cannot read secrets, but its deployment token can request a task definition containing secret references. It posts those references and internal endpoints into a broadly visible log. Minutes later it attempts to change the log retention setting after the same instruction calls old logs unnecessary.

The first response is to disable the agent's tool exchange, not merely revoke the repository token. Revoke active tool sessions, block new exchanges, preserve policy and approval logs, and stop the affected workflow. The security lead owns containment and evidence. The system owner checks whether exposed references can be used to retrieve secret values. The fractional CTO decides whether to halt all automated releases or use a human release path while the team investigates.

Next, trace the run identifier across retrieval, planning, policy decisions, credential issuance, and downstream API calls. Determine which data left its intended boundary and whether any action succeeded. Rotate credentials based on exposure, not anxiety: rotate a secret if the agent or an unintended reader could obtain its value, and invalidate references if they can be redeemed. A blanket rotation without a dependency map can cause a second outage and erase useful timing evidence.

Recovery requires more than changing the prompt. Add an enforcement rule that prevents the deployment identity from reading task definitions beyond the fields required for rollout. Redact sensitive reference paths from logs, reject retention changes, add the poisoned issue to a regression test, and verify that the agent can still deploy. The CTO owns the redesigned workflow. The security lead verifies the boundary and closes the incident only after monitoring can detect a repeat.

Write the handoff conditions into the incident plan. Security takes command when the agent acts outside authorization, exposes protected data, shows signs of hostile influence, or defeats a control. Technology leadership takes command when the agent remains within authorization but causes a service defect. Both stay involved when containment affects revenue, customer commitments, regulated reporting, or a major recovery decision.

Both roles must collaborate at boundary changes

The fractional CTO and security lead must collaborate whenever an agent gains a new action class, crosses a trust boundary, handles more sensitive data, or can create consequences outside one team's recovery authority. Collaboration does not mean both people review every prompt edit. It means neither can approve a material boundary change alone.

Use a joint review for these changes:

• moving from read access to write access;
• connecting production, identity, payment, or customer data systems;
• replacing per action approval with standing authority;
• allowing one agent to call another agent with separate privileges;
• changing the emergency or incident control path.

Multi-agent systems deserve special care. If a planner without production access can direct an executor that has it, the planner influences a privileged action. The executor must enforce its own policy and cannot trust the upstream agent's claim that approval exists. Pass a verifiable approval reference and bind it to the final action. Never treat the internal network or shared orchestrator as proof of authority.

Delegation should narrow authority. An agent that creates a subtask for another agent must not confer permissions it does not hold, extend the original expiration, or change the approved target. This is the same reason a service identity should not be able to mint arbitrary sibling identities. The security lead defines delegation invariants, while the CTO decides whether the added coordination earns its operational cost.

Data classification changes also trigger joint review. An agent may begin with public documentation and later gain support tickets containing personal or confidential data. Its action list can stay identical while the consequence of prompt logging, retrieval, and model submission changes. The CTO owns the new workflow purpose and provider architecture. Security owns the data controls, retention checks, and revised incident threshold.

Set a short, fixed review for active privileged agents, and review immediately after a material change or incident. The meeting should examine denied actions, unused privileges, emergency grants, approval quality, policy exceptions, and drift between the stated purpose and actual calls. Remove unused actions. Repeated denials may reveal an attack, a broken workflow, or an undocumented need; do not automatically expand access to make the errors disappear.

A small company still needs separation

A startup without a full time security lead should assign the security decision to a named person or retained specialist, not leave it inside a generic engineering responsibility. The fractional CTO can build the first control model, but someone independent must challenge high impact access and own the response checklist.

For an early production deployment, a workable minimum has four named roles even if two people fill them: executive risk owner, technology owner, security reviewer, and system operator. Record role changes and backups. An access policy that names a departed contractor as its only approver is an outage waiting for the next urgent release.

The minimum operating package is small enough to maintain. Keep an inventory of agents, owners, identities, tools, data classes, and expiration dates. Store each access policy beside the workflow code and require review for privilege changes. Before production, test one allowed action, one denied action, control failure, credential expiry, and emergency disable. Route privileged events into a log the agent cannot alter, with alerts for denied and restricted actions. Run a short incident exercise that includes disabling the agent and switching to a human process.

Do not buy a privileged access product before defining these decisions. A tool can issue short lived credentials and collect evidence, but it cannot decide whether an agent should be allowed to refund a customer or rebuild a database. Undefined ownership becomes a complicated configuration with the same undefined ownership.

A Team & AI Audit can map these decision rights alongside the engineering workflow, identify where agent access saves labor, and put a price on the controls needed for production. That work is most useful before broad permissions harden into dependencies, though an existing deployment can still be reduced action by action.

Budget for security work as part of the automation, not as an external tax. The cheapest design often gives the agent fewer direct tools and a better handoff to a person. One narrowly scoped executor is easier to review than several agents sharing a powerful credential, even if the latter looks faster in a demonstration.

Test ownership with one access request

You can judge the operating model by following one real request from purpose to incident response. Pick the next privileged capability an agent asks for and require an answer to every decision before granting it.

The fractional CTO should state the business outcome, explain why direct execution is justified, identify the systems and data involved, set acceptable failure consequences, and name the human fallback. The system owner should define exact resources and recovery steps. The security lead should classify each action, write control requirements, verify denied paths, define evidence, and set containment triggers. The executive risk owner should approve any residual consequence that exceeds those mandates.

Then ask who can disable the agent at 2 a.m., who may stop production to preserve evidence, who tells customers or regulators if needed, and who decides the service can return. If the answer is the team, ownership is still missing. Put names and thresholds in the runbook.

Grant the smallest useful capability with an expiration date. Watch actual calls for a week or a representative operating cycle, then remove unused actions and inspect denials. Do not expand permission merely because a model asks repeatedly. Fix the workflow or bring the request back through the same decision path.

A fractional CTO should own the reason and architecture for privileged automation. A security lead should own its enforceable limits and security response. The company needs both at the moment an agent can create a consequence that one role cannot independently accept or repair. That boundary, not seniority or title, decides when collaboration is mandatory.