Giving an EA Access to Everything: What the Real Risk Is

The first time someone asked for my calendar password, I said no.

Not out loud. I just stalled. I said I would "set something up" and then I did not, for three weeks. The EA I had just brought on sat there with almost nothing to do because the one thing she needed, access to my actual life, was the thing I could not bring myself to hand over.

I have talked to enough founders since then to know this is the real blocker. Not cost. Not whether the person is good. The sticking point is that hiring an EA means giving a stranger the keys to your inbox, your calendar, your travel accounts, sometimes your money. That feels insane the first time you say it out loud.

So let me say the uncomfortable part first. The risk you are worried about is not the risk that will actually hurt you.

What founders are actually afraid of

When founders describe this fear, they describe theft. Someone gets into the bank login and drains an account. Someone forwards a sensitive email to a competitor. Someone screenshots a board deck and sells it.

These things can happen. They are also rare, and they are the easiest risks to control. I will get to how in a minute.

The fear underneath the fear is harder to admit. It is loss of control. For most founders, the inbox is the nervous system of the company. You know where everything is because everything passes through you. Handing that over does not feel like a security decision. It feels like giving up the one place where you still know what is going on.

That is the real resistance. And it is worth naming, because the solution to a control problem is different from the solution to a security problem. You can solve security with tools. You solve control by deciding you would rather have leverage than visibility into every thread.

The risk nobody puts on the list

Here is the cost that never shows up when founders weigh this decision.

You stay the bottleneck. Every approval routes through you. Every scheduling conflict waits for you. Every vendor email sits unread for four days because you are the only person who can see it. The company moves at the speed of your inbox, and your inbox is full.

I ran the numbers on my own situation once. I was spending roughly 11 hours a week on email and calendar work. At the value I put on my time, that is over $200,000 a year of founder attention spent on tasks a trained assistant handles better than I do. I wrote about that math in detail in the founder's $200K mistake, and the number still bothers me.

The point is that "I am not comfortable giving access" is not a neutral position. It has a price. The price is that you keep doing $30-an-hour work at a $200-an-hour cost, indefinitely, because you are protecting against a small risk by accepting a large and certain one.

The fear of theft is vivid. The cost of staying the bottleneck is boring. Boring usually wins the long game.

How access actually works now

A lot of the fear comes from an outdated picture of what "giving access" means. Founders imagine writing their bank password on a sticky note and emailing it over. That is not how any of this works anymore, and if a service or assistant ever asks you to do that, walk away.

Here is what real access looks like.

You use a password manager. The good ones let you share a login without ever showing the person the password itself. The assistant clicks a button and gets into the account. They never see the characters. You can revoke that access in two clicks, and the moment you do, they are locked out of everything at once. No scrambling to change a dozen passwords because someone left.

For email and calendar, you do not share a password at all. Major email platforms let you delegate access as a separate permission. The assistant logs in as themselves, with their own credentials, and acts on your inbox through a delegation layer. Every action is attributable to their account. You can see exactly what they did. You can pull it back instantly.

For money, you almost never grant full access. You grant scoped access. View-only on the accounts where they only need to reconcile. A spending limit on the card they use to book travel. Approval required above a threshold you set. The assistant can do the work without ever being able to move real money on their own.

None of this is exotic. It is the same access model that any company with a finance team already runs. The difference is that most founders have never set it up for themselves because they never had anyone to delegate to.

Start small, then widen the door

You do not hand over everything on day one. You should not, even if you trust the person completely, because you do not yet know how they work and they do not yet know your standards.

The approach that worked for me was a trust ramp. Week one, calendar only. Read access to my inbox so the assistant could understand context, but no sending on my behalf. That alone took the scheduling load off me without exposing anything sensitive.

By week three, she was drafting replies for me to approve and sending routine confirmations on her own. By week six, she had the travel accounts and a card with a $3,000 monthly limit. By month three, the only things I had not delegated were the two or three accounts a founder should probably never delegate, like the master domain registrar and the primary banking admin.

This is the same logic I use for any new hire. I wrote a full version of it in what to hand off on day one. The principle is simple. Access expands with demonstrated judgment. You are not granting trust as a leap of faith. You are granting it in increments, based on what you have actually seen.

A founder who tries to delegate everything in week one and a founder who refuses to delegate anything are making the same mistake from opposite directions. Both are treating access as a single switch. It is a dial.

What a real service puts behind the access

If you are working with a managed service rather than a lone freelancer, the access question changes shape. Now you are not just trusting one person. You are trusting the structure around that person, and that structure is most of what you are paying for.

The things worth requiring before you grant access to anyone placed by a service:

Background checks on every assistant, run before placement, not promised vaguely. Ask to see what the check covers.

Signed confidentiality agreements that name your company, not a generic boilerplate the assistant signed once two years ago.

Liability coverage at the service level. If an assistant causes real financial damage, there should be an insured entity standing behind that, not just an individual you would have to chase yourself.

A clear off-boarding process. When an assistant leaves, who revokes access, how fast, and how do you confirm it happened? This is the question almost nobody asks and the one that matters most, because the highest-risk moment is not while someone works for you. It is the week after they stop.

This is also where the difference between a managed service and a raw staffing placement gets concrete. With a placement, the security and accountability layer is your problem to build. With a managed service, it is the service's obligation to maintain. I broke down the rest of that difference in managed services versus staffing agencies, but on the access question specifically, the gap is wide. One model hands you a person. The other hands you a person plus the controls around them.

The contrarian part

Here is what I actually believe after years of this. The biggest security risk in your setup is not the assistant. It is you.

Your password is reused across six sites. Your recovery email has no two-factor on it. You have logged into your bank on hotel wifi. You forward sensitive documents to your personal Gmail so you can read them on your phone. You have an old laptop in a drawer that is still signed into everything.

A trained assistant working through a password manager with scoped permissions and delegated access is, in most cases, more disciplined with your accounts than you are. They were set up correctly from the start. You accreted bad habits over a decade.

When founders tell me they cannot risk giving an assistant access, I sometimes want to ask when they last audited their own. The honest answer is usually never. The person you are afraid to let in often improves your security posture, because bringing someone on forces you to set things up properly for the first time.

That is the part that flips the whole question. Done right, hiring an EA does not weaken your security. It is the event that finally makes you fix it.

The decision underneath the decision

Strip away the password-manager mechanics and the real choice is plain. You can keep total control and stay the constraint on your own company. Or you can give up the illusion that being the only person with the keys is the same as being safe, and trade it for actual leverage.

Control feels like safety. It is usually just friction wearing a costume.

I am not telling you to be careless. Run the background check. Use the password manager. Scope the money access. Build the trust ramp. Confirm the off-boarding works. Do all of it. Those steps reduce the real risk to something close to noise.

What I am telling you is that "I am not comfortable with the access" is not the end of the conversation. It is the start of one. The discomfort is real and the fix is known. The only question is whether you would rather sit with the discomfort or solve it and get your week back.

If you want to see how a thoughtful access and onboarding process works in practice, apply for access and we will walk you through exactly what gets shared, when, and how you keep control of every bit of it.